这是一个创建于 65 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在做优化，android java,
性能分析时意外发现这个 offer 占用了不大不小的时间，
具体是个线程池(Executors.newFixedThreadPool)用到 new LinkedBlockingQueue<Runnable>(), 大量 submit 任务时 offer 耗时了，挺意外的，
不管怎么搜索都是告诉我 offer 不会等待， 那为什么 offer 耗时这么大呢？
而且 offer 中耗时的方法名是“art_jni_trampoline”， 看起来是安卓相关的，这不在 offer 源码里， 不知道这说明什么，
性能分析时意外发现这个 offer 占用了不大不小的时间，
具体是个线程池(Executors.newFixedThreadPool)用到 new LinkedBlockingQueue<Runnable>(), 大量 submit 任务时 offer 耗时了，挺意外的，
不管怎么搜索都是告诉我 offer 不会等待， 那为什么 offer 耗时这么大呢？
而且 offer 中耗时的方法名是“art_jni_trampoline”， 看起来是安卓相关的，这不在 offer 源码里， 不知道这说明什么，
4 条回复 • 2024-09-10 14:11:03 +08:00
 |
1
hysli 65 天前
是不是任务太多，导致队列满了，队列满了就会等待吧。
|
 |
2
AoEiuV020JP OP @hysli #1 任务是太多，但一方面 LinkedBlockingQueue 默认参数队列是无上限的， 一方面 offer 遇到队列满了会直接返回不会阻塞，所以很奇怪，
|
 |
3
ysc3839 65 天前 via Android
感觉是在等待锁
|
 |
4
sinalvee 65 天前
LinkedBlockingQueue 有 putLock 和 takeLock 两个锁，offer 方法要获取 putLock ，默认参数的时无界队列所以不会直接返回 false ，任务太多了等待锁的时间就会变长
|
Select Language