@Lighfer https://github.com/smartisanyyh/gracefulshutdowntrace 麻烦帮忙看看呢... 我看了下除掉 daemon 线程 有台机器上有些 rabbitmq 的连接没有关,另一台机器好像要正常许多 但是进程也没有掉

@Lighfer 终于被我逮住了 又发生了两次 我 jstack 看了 我把文件 down 下来了 怎么分享出来给大家一起看呢 V2EX 咋分享文件啊

@dzh213 可能是还有别的线程池没关到吧 我也觉得 但具体是哪个有点不好找

@Kyle18Tang 对啊 这个.service 文件里有 stop 的命令,但这个 stop 命令不还是自己写的吗 他只是把你写的 stop 命令执行了一下

@AmmeLid 收到 我下周再试试 这个不是必然发生的 测试环境基本没有过 生产我们是双机 昨天测试的时候一台没 kill 掉 一台 kill 掉了

systemctl 下边的停止命令还是自己写的啊 还不是得写 kill-15 应该没啥区别吧
@Kyle18Tang

@Kyle18Tang 我们并没有把他做成系统服务 稍后我可以试试

@dzh213 有没有办法看 java 中还在运行的所有线程啊 我这边没有单独开其他线程了 也没有定时任务

@qfdk 我没用 actuator 就是加了个钩子函数关闭 tomcat 线程池 在外边杀进程用的是 kill-15 ,很奇怪就是生产上不行 而且看日志 线程池是关完了的 就是进程一直在

@leonard916 版本不是你想升 想升就能升

@ppyybb 哦哦,原来是这样,两年前的内容都还记得也是很厉害了,我是因为疫情原因,在家没事干,学习下 AQS,发现这里可能会有点问题就提出来大家一起讨论一下,也感谢大家跟我一起讨论,祝大家身体健康,工作顺利

@ppyybb 在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了

在每次 submit 的时候睡一下是不科学的一是因为时间原因,每个线程都睡太耗时间了;二是因为这样也不能确保所有线程同时 take,睡了的话上一个线程反而会执行到 await 把锁释放了

@ppyybb 我说的就是主线程 poll 之前 sleep 一下,确保上边的线程执行完毕全部进入阻塞状态,如果上边的线程全部都在 await 的话入 sync 队列的 node 数量就是 0 了呀,这样就不会有延迟
我是说这样不会有问题
你应该想说的为了证明这个问题 应该在每次 submit 的时候睡一下确保上一个线程在执行 takeLock.lockInterruptibly()?

@ppyybb 我试过的,直接主线程睡会儿再执行 poll(1000, TimeUnit.MILLISECONDS)就好了,只要 AQS 队列里没有排队的 node 这个方法还是很及时的,主要就是看是否有大量线程在抢锁,如果有,那么 poll(1000, TimeUnit.MILLISECONDS)就可能超过指定时间返回,awaitNanos(nanos)相比 await 只是多了一个自我唤醒的步骤,唤醒之后还是得抢锁,但是由于非公平锁的原因确实不好测试,有可能两次抢锁都一下就抢到了而不仅 AQS 队列

@ppyybb
1.线程是同步创建的,循环完了线程应该就创建完了,不存在等待线程创建地说法
2.take 方法执行到 notEmpty.await()的时候 这些 node 确实会 condition 队列里,但是 take 方法一进来就有 takeLock.lockInterruptibly()抢锁的操作,理想状态 100000 个线程同时抢锁只有一个抢到其余的应该进 AQS 队列(事实上并没有这么多线程进入队列,因为非公平锁和线程并不是同时启动的原因)
3.此时主线程调用 poll(1000, TimeUnit.MILLISECONDS)方法,这个方法会抢两次锁第一次为 takeLock.lockInterruptibly(),第一次抢锁的时间并没有计入等待时间,然后执行 notEmpty.awaitNanos(nanos),挂起当前线程,等待传入时间结束之后唤醒当前线程,并将当前 node 移入 AQS 队列,再次抢锁,由于两次抢锁都是非公平的所以都有可能一来就抢到,而不进 AQS 队列,理想状态为两次都进入队列,然后等待其他线程挨个 unlock 唤醒下个线程,这样时间就有可能会长

淦 为啥我的图不显示

xxx