poll(long, timeunit) 超时后返回 null 表示队列为空且等待超时，是可检测的空闲信号，而非错误；应结合时间戳计算累计空闲时长触发资源回收，而非仅依赖 null 次数。
poll(long, TimeUnit) 返回 null 时意味着什么
调用 poll(timeout, unit) 超时后返回 null，不是异常，而是明确信号：队列空且等待超时。这和 take() 阻塞不同，它把“空闲”变成了可检测的状态，是资源回收的起点。
常见误判是把 null 当成错误处理，比如抛 IllegalStateException 或重试——这反而阻碍了退出逻辑。真正该做的是：确认空闲持续时间是否达到回收阈值。
- 必须配合循环计数或时间戳，单次
null不代表长期空闲 - 不要在
catch (InterruptedException e)外忽略中断状态；应主动检查Thread.interrupted() - 若消费者还持有外部资源（如数据库连接、文件句柄），
null是释放它们的安全时机
如何用累计空闲时间触发回收而不是轮询次数
单纯靠“连续 poll 返回 null 次数”容易受 GC、调度抖动影响，导致过早或过晚回收。更稳的方式是记录上次成功消费时间，每次 poll 超时后计算差值。
long lastActiveNanos = System.nanoTime();
while (running) {
Task task = queue.poll(500, TimeUnit.MILLISECONDS);
if (task != null) {
lastActiveNanos = System.nanoTime();
process(task);
} else {
long idleNanos = System.nanoTime() - lastActiveNanos;
if (idleNanos > TimeUnit.SECONDS.toNanos(30)) {
releaseResources();
break;
}
}
}
-
System.nanoTime()比System.currentTimeMillis()更适合测空闲时长，不受系统时钟调整影响 - 超时时间（如
500ms）不宜设为 0（退化成poll()）或过大（延迟响应 shutdown） - 回收前建议加一次
queue.peek() != null双检，避免竞态下刚有新任务入队就被误判
shutdown 过程中 poll(time) 的中断行为要怎么配合
当外部触发关闭（如 Spring 的 @PreDestroy 或显式 shutdown()），消费者线程需快速退出，不能卡在下一次 poll 上。关键点在于：中断优先级高于超时。
- 调用
thread.interrupt()后，poll(timeout, unit)会立即抛InterruptedException，不会等到超时 - 必须在
catch (InterruptedException e)中做两件事：恢复中断状态（Thread.currentThread().interrupt()）、跳出循环 - 不要吞掉中断异常，也不要只打日志就继续循环——这会让 shutdown 等待超时甚至失败
BlockingQueue 实现类对 poll(time) 行为的影响
不同实现对超时精度和中断响应略有差异，不能一概而论：
-
ArrayBlockingQueue和LinkedBlockingQueue行为一致，超时可靠，推荐用于可控场景 -
PriorityBlockingQueue不支持公平等待，poll(time)超时逻辑正常，但无排序保障，慎用于需严格 FIFO 回收的场景 -
SynchronousQueue的poll(time)等价于“等一个生产者送数据”，空闲判定意义弱，不适合做资源回收依据
如果用了 DelayQueue，注意它的 poll(time) 只在队首元素到期后才可能返回非 null，空闲判断逻辑要额外考虑延迟时间，否则会误判。
