使用`LinkedBlockingQueue`可能会导致空指针异常 [英] Using ` LinkedBlockingQueue` may cause null pointer exception

问题描述

我最近正在学习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();
    }
}

推荐答案

根据此博客文章

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.

简而言之，在三种情况下，我们会产生跟踪障碍:

In short, we emit a trailing barrier in three cases:

写了最后一个字段.注意，我们并不关心实际写入的字段，我们在退出(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`可能会导致空指针异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！