我遇到Writer线程饿而没有锁的问题。
请看下面的代码。如果我尝试使用tryLock()来获取读取锁，则写入程序进程将变得饥饿，并且将永远无法写入。即使公平，编写者进程也将完全饿死并且永远不会执行。相反，如果我只尝试reader.readLock()，那么编写器进程将能够获取锁。
请一定让我知道是否丢失了某些东西，即使Writer进程线程设置为高优先级，它也永远不会得到锁定，而会在等待锁定时卡住。
谁能告诉我是否可以将trylock()与ReadWriteLocks一起使用。
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.locks.*;
class ReadWrite{
private int a, j=0,k =0;
private final ReentrantReadWriteLock asd = new ReentrantReadWriteLock();
private final Lock readlock = asd.readLock();
private final Lock writelock = asd.writeLock();
ReadWrite(){
a = 0 ;
}
ReadWrite(int a){
this.a = a;
}
public int read() {
try {
if (readlock.tryLock())
{
//readlock.lock();
k = k + 1;
if (k%100000==0) {
System.out.println("read " + k + " times ==> Written " + j + " times");
}
readlock.unlock();
return a;
}
}
catch(Exception E) {
System.out.println(E);
return a;
}
return 0;
}
public void write(int a) {
int k = 9;
try {
writelock.lock();
//writelock.lock();
this.a = a;
k = 0;
j = j + 1;
System.out.println("Acquored");
}
catch(Exception E) {
System.out.println(E);
}
finally {
if (k == 0 )
writelock.unlock();
}
}
}
class reader implements Runnable{
ReadWrite a;
reader(Object b){
a = (ReadWrite) b;
}
public void run() {
while(true) {
try{a.read();
//Thread.sleep(100);
}
catch(Exception E) {
}
}
}
}
class writer implements Runnable{
ReadWrite a;
writer(Object b){
a = (ReadWrite) b;
}
public void run() {
//Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
while(true) {
try {
//Thread.sleep(1);
}
catch(Exception E) {
}
a.write((int) Math.ceil(Math.random()*100));
}
}
}
class Practice{
public static void main(String args[]) {
ReadWrite a = new ReadWrite();
System.out.println("Invoking Write Thread");
ExecutorService asd = Executors.newFixedThreadPool(100);
asd.execute(new writer(a));
for (int i = 0 ; i < 98 ; i ++)
asd.execute(new reader(a));
}
}
最佳答案
在这种情况下，如果不公平地使用ReentrantReadWriteLock，将永远无法工作：太多的读取器线程只会使写入器线程饿死。
公平地说，编写者线程将偶尔有机会进行编写。
然而，事实证明，在代码中将ReentrantReadWriteLock设置为“ fair”是徒劳的。这是事实：您的读者不使用lock()，而是使用tryLock()。因此，他们永远不会排队获取锁，只要有锁就可以获取。通过不排队（在内部ReentrantReadWriteLock中），他们规避了公平政策。
注意tryLock()对象上ReadLock上的javadoc：
仅当调用时另一个线程未持有写锁时才获取读锁。
如果写锁未被另一个线程持有，则获取读锁，并立即返回true值。即使已将此锁设置为使用公平的排序策略，对tryLock（）的调用也会立即获取读取锁（如果可用），无论其他线程当前是否在等待该读取锁。即使破坏公平性，这种“讨价还价”的行为在某些情况下还是有用的。如果要遵守此锁的公平性设置，请使用几乎等效的tryLock（0，TimeUnit.SECONDS）（它还会检测到中断）。
如果写锁由另一个线程持有，则此方法将立即返回false值。
（强调我的）