问题描述
我最近正在学习Java并发编程.我知道final
关键字可以保证发布的安全性.但是,当我阅读LinkedBlockingQueue
源代码时,发现head
和last
字段未使用final
关键字.我发现enqueue
方法在put
方法中被调用,并且enqueue
方法直接将值分配给last.next
.此时,last
可能是null
,因为last
没有用final
声明.我的理解正确吗?尽管lock
可以保证last
读写线程的安全性,但是lock
可以保证last
是正确的初始值而不是null
I am learning java concurrent programming recently. I know that the final
keyword can guarantee a safe publication. However, when I read the LinkedBlockingQueue
source code, I found that the head
and last
field did not use the final
keyword. I found that the enqueue
method is called in the put
method, and the enqueue
method directly assigns the value to last.next
. At this time, last
may be a null
because last
is not declared with final
. Is my understanding correct? Although lock
can guarantee last
read and write thread safety, but can lock
guarantee that last
is a correct initial value instead of null
public class LinkedBlockingQueue<E> extends AbstractQueue<E>
implements BlockingQueue<E>, java.io.Serializable {
transient Node<E> head;
private transient Node<E> last;
public LinkedBlockingQueue(int capacity) {
if (capacity <= 0) throw new IllegalArgumentException();
this.capacity = capacity;
last = head = new Node<E>(null);
}
private void enqueue(Node<E> node) {
// assert putLock.isHeldByCurrentThread();
// assert last.next == null;
last = last.next = node;
}
public void put(E e) throws InterruptedException {
if (e == null) throw new NullPointerException();
// Note: convention in all put/take/etc is to preset local var
// holding count negative to indicate failure unless set.
int c = -1;
Node<E> node = new Node<E>(e);
final ReentrantLock putLock = this.putLock;
final AtomicInteger count = this.count;
putLock.lockInterruptibly();
try {
/*
* Note that count is used in wait guard even though it is
* not protected by lock. This works because count can
* only decrease at this point (all other puts are shut
* out by lock), and we (or some other waiting put) are
* signalled if it ever changes from capacity. Similarly
* for all other uses of count in other wait guards.
*/
while (count.get() == capacity) {
notFull.await();
}
enqueue(node);
c = count.getAndIncrement();
if (c + 1 < capacity)
notFull.signal();
} finally {
putLock.unlock();
}
if (c == 0)
signalNotEmpty();
}
}
推荐答案
根据此博客文章 https://shipilev.net/blog/2014/safe-public-construction/甚至在构造函数中写入一个final
属性也足以实现安全初始化(因此,您的对象将始终被发布安全地).并且capacity
属性声明为final
.
According to this blog post https://shipilev.net/blog/2014/safe-public-construction/ even writing to one final
property in constructor is enough to achieve safe initialization (and thus your object will be always published safely). And capacity
property is declared as final
.
写了最后一个字段.注意,我们并不关心实际写入的字段,我们在退出(initializer)方法之前无条件地发出了屏障.这意味着,如果您至少有一个final字段写,则final字段的语义会扩展到构造函数中编写的所有其他字段.
A final field was written. Notice we do not care about what field was actually written, we unconditionally emit the barrier before exiting the (initializer) method. That means if you have at least one final field write, the final fields semantics extend to every other field written in constructor.
这篇关于使用`LinkedBlockingQueue`可能会导致空指针异常的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!