排查线程池插件增强失败的问题

插件配置问题

• 将插件 jar 包移动到 plugins 目录下，但应用启动后插件未生效。
• 测试简化配置，仅保留 tomcat-7.x-8.x-plugin 和 apm-jdk-threadpool-plugin，发现线程池插件生效。

类加载器实例化问题

• 发现 AgentClassLoader 实例化了两次，导致扫描 jar 包的日志多次输出。
• 调试 AgentClassLoader 的构造器，发现第一次在 premain 方法启动时实例化，第二次在 main 方法启动时加载插件时再次实例化。

日志扫描与依赖问题

• 在 InterceptorInstanceLoader 中发现，扫描 jar 包的逻辑存在缓存问题，可能导致多次扫描。
• 发现 ThreadPoolExecutor 类在日志组件 FileWriter 中被多次依赖，导致增强失败。

类加载顺序分析

• 启动时开启 TraceClassLoading，观察到 ThreadPoolExecutor 类在 transform 阶段被依赖。
• 发现 ThreadPoolExecutor 在 FileWriter 中的初始化触发了 transform，而 transform 阶段依赖已加载的 ThreadPoolExecutor 类，导致循环依赖问题。

解决方案

• 修改 AgentClassLoader 为单例模式，避免重复实例化和多次扫描 jar 包。
• 在 FileWriter 中注释掉线程池的初始化代码，改为其他实现方式，避免对 ThreadPoolExecutor 的依赖。

线程池插件为什么会失败？

• 插件的字节码增强在类加载阶段进行，依赖类的加载顺序。
• 如果已加载的类依赖需要增强的类，可能在 transform 阶段失败。

重复实例化的影响

• AgentClassLoader 实例化多次，导致日志多次输出，可能引发多次扫描 jar 包。
• 重复扫描可能导致对 ThreadPoolExecutor 类的多次依赖，触发 transform 逻辑。

JVM 类加载机制的限制

• JVM 对已加载类的 transform 有限制，可能避免循环依赖导致的问题。
• 重复扫描 jar 包可能触发多次对 ThreadPoolExecutor 的依赖，导致增强失败。

确保插件单例

• 修改 AgentClassLoader 为单例模式，避免重复实例化和多次扫描 jar 包。

优化日志组件

• 在 FileWriter 中注释掉线程池的初始化代码，改为其他实现方式，避免对 ThreadPoolExecutor 的依赖。

简化插件测试

• 单独测试插件，确保每个插件的增强逻辑独立，不互相依赖。