调用ArrayBlockingQueue.poll()时CPU占用高是正常现象还是代码错误？

• 该现象属于正常情况，ArrayBlockingQueue.poll()的使用逻辑不存在错误。

1. 采样统计的特性导致
   当前使用Async-profiler的itimer模式采样，该模式依赖定时器信号触发栈回溯。当线程从__pthread_cond_timedwait挂起状态被唤醒、回到CPU执行的瞬间，如果刚好触发采样信号，栈回溯就会捕获到__pthread_cond_timedwait栈帧，进而被计入统计结果。如果切换为CPU周期采样模式，该函数的占比会进一步降低，仅统计其真正消耗CPU的执行片段。

2. 等待函数本身存在固有开销
   __pthread_cond_timedwait并非完全不消耗CPU：函数入参校验、内核态等待队列注册、超时/唤醒后的资源清理、用户态内核态上下文切换，都存在少量CPU开销。你使用100ms超时的轮询逻辑，每次超时或者队列有新元素时都会触发这部分开销，累积下来就会在采样结果中呈现出一定占比。当前仅2.65%的占比属于完全可接受的正常范围。

3. 代码逻辑正确性验证
   你代码中poll返回null直接进入下一轮循环的逻辑符合ArrayBlockingQueue的使用规范，也正确处理了中断、虚假唤醒的场景，不存在使用错误。

如果业务对队列消费延迟不敏感，可以适当调长poll的超时时间，减少线程频繁超时唤醒的次数，降低上下文切换和等待函数的调用频次。当前2.65%的占比极低，没有优化必要，不会影响业务整体性能。

内容的提问来源于stack exchange，提问作者srg321