@ETiV 做了排除的脚本里 现在问题可以简单描述为
/bin/bash -x /opt/8848/springboot.sh stop /opt/8848/dfepay-api-1.0.0.jar java 有问题 如果第三个参数不加 或者传其他的都没问题 就是传 java 就会有问题

@Kyle18Tang 本质上和自己写脚本没有区别, 只是官方写了一段脚本让我们可以更方便的做成系统服务

@Kyle18Tang 我把生产上的服务变成了 service 启动 ,观察后发现还是有这个问题 ,执行完钩子函数后应用没有停止,因为 service stop 有超时时间所以一段时间后会强制结束进程

正常点的那台机器上只有三个线程不是 daemon 都处于 waiting 状态

"DestroyJavaVM" #37 prio=5 os_prio=0 tid=0x00007f8d38008800 nid=0x49e waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"container-0" #20 prio=5 os_prio=0 tid=0x00007f8d39033800 nid=0x4bb waiting on condition [0x00007f8ce34f9000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.core.StandardServer.await(StandardServer.java:427)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer$1.run(TomcatEmbeddedServletContainer.java:177)



"Thread-3" #36 prio=5 os_prio=0 tid=0x00007f8ca8001000 nid=0x2e4e waiting on condition [0x00007f8ca0dda000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000086ede2a8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1475)
at com.dooffe.epay.common.api.DooffeEpayApiApplication$GracefulShutdown.shutDownThreadPool(DooffeEpayApiApplication.java:79)
at com.dooffe.epay.common.api.DooffeEpayApiApplication$GracefulShutdown.onApplicationEvent(DooffeEpayApiApplication.java:69)
at com.dooffe.epay.common.api.DooffeEpayApiApplication$GracefulShutdown.onApplicationEvent(DooffeEpayApiApplication.java:53)
at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:393)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:347)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:991)
at org.springframework.context.support.AbstractApplicationContext$2.run(AbstractApplicationContext.java:929)
- locked <0x0000000085fe8e38> (a java.lang.Object)

@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 队列