试试 bootstrap.properties

大概因为是局部变量。
困惑的点应该是有一个理解误区，就是线程池中的线程其实不对 ExecutorService 实例产生引用。
在 ExecutorService 局部变量生命周期结束后也就不存在外部对它的引用，这个对象可以被回收，进而停掉线程池，然后等待线程执行正常结束。

已经提到的一点问题就是目前打包的 jar 是平铺的，如果不怕费事：
1. 可以使用 maven-dependency-plugin 把这几个依赖项 unpack 到 classes 下一个目录进行打包,同时自定义类加载器适配 jar 内这个目录下的那些类。
2.也可以直接做 shade 配合 relocation,只是会影响运行时类名，在提供二方三方使用时需要注意，反射也需要注意。

我使用过方案一完成过一些功能，和你需求不一样但应该能达到一样的效果。

@lc5900 你是说可能存在异步导致开始时间错误最终看到的调用顺序吗

@liuxu consumer 侧不加入 span ，定位问题会出现什么困难呢？这个没有想到

请问有接入 javaagent 吗？有的话是否依然兼容呢？

87

源代码混淆可以使用 proguard ，源代码加密可以使用 xjar(运行时可被查看比如 arthas jad )

@wxw752 有集群实现方案吗

看起来很大概率是这样的。

破案 jvm 问题
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8156137

https://bugs.openjdk.org/browse/JDK-8156137

@1194129822 内存整理的话，他这个时间也太长了，只要达到这个状态，一晚上不管他的话第二天还是打满的 cpu 。。。

@1194129822 最初始的内存配置是 -Xmn768m -Xms2g -Xmx2g ，后来发现是新生代满后就尝试对内存放大，但是没效果，即便新生代最后放到 2g 一样打满

根据 jstack -m 的日志很可能是一直保持在这个方法执行，在 do-while 内。
https://github.com/JetBrains/jdk8u_hotspot/blob/c39701c890a5960dfa7c325b78ee97085646f57d/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp#:~:text=void%20ParEvacuateFollowersClosure%3A%3Ado_void()%20%7B

@chendy 都加着呢不会 OOM

@dqzcwxb 应用已经假死了，还在执行的线程都是 GangWorker, 同时会有一个 worker 处于 wait 状态，其他的处于满载状态

@zeni123 eden 调大无效，最初始是 768M ，最大调过 -Xms4g -Xmx4g -Xmn2g 年轻代还是会爆满，老年代很空闲


二楼说的对,Ready 要保证内存可见性