1.从代码上看只是开放了setCapacity的入口,且capacity是通过volatile修饰的,所以capacity的变化会及时通知到各个线程,
关键问题是,当我往队列里插入或者取对象的时候,会有个判断
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;
ResizableCapacityLinkedBlockIngQueue.Node node = new ResizableCapacityLinkedBlockIngQueue.Node(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();
}
1.从代码上看只是开放了setCapacity的入口,且capacity是通过volatile修饰的,所以capacity的变化会及时通知到各个线程, 关键问题是,当我往队列里插入或者取对象的时候,会有个判断 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; ResizableCapacityLinkedBlockIngQueue.Node node = new ResizableCapacityLinkedBlockIngQueue.Node(e);
final ReentrantLock putLock = this.putLock;
final AtomicInteger count = this.count;
putLock.lockInterruptibly();
try {
/*
如果这个时候我调整了假设当前的任务数量是100,capacity是200,现在我调整capacity的大小为50,这个时候根据这个判断count.get() == capacity,任务队列是没有满的,这样还会往队列里塞数据,不知道我理解的对不对,是不是调整为count.get()>=capacity