Java反射不能监听对象创建，Instrumentation需通过字节码增强在方法中插入监控逻辑，覆盖new、反射、DI等所有创建路径。
不能直接用反射监听对象创建，Instrumentation 本身也不提供“监听 new 实例”这种粒度的钩子。Java 的 java.lang.instrument 机制不拦截构造调用，而是通过字节码增强（ClassFileTransformer）在类加载时修改目标类的字节码，在构造方法（<init></init>）入口或出口注入监控逻辑——这才是实际可行、生产环境验证过的方案。
核心思路：在构造器中插入监控字节码
Instrumentation 不感知“对象创建事件”，但能让你改写任意类的字节码。关键操作是：
- 注册
ClassFileTransformer，过滤出你关心的类（如com.example.User或按包名批量匹配） - 在目标类的每个
<init></init>方法开头插入计时开始逻辑（例如记录System.nanoTime()） - 在每个
<init></init>方法末尾（所有 return 指令前）插入耗时统计与上报逻辑 - 避免修改异常路径——需处理
athrow指令分支，否则构造失败时漏统计
需要避开的典型误区
很多人误以为可以靠反射 + ClassLoader.defineClass 或 ObjectStreamClass 拦截实例化，这些方式要么不可控（反射不参与构造调用链），要么仅适用于序列化场景，无法覆盖 new、newInstance、工厂模式、依赖注入容器等主流创建路径。真正全覆盖，必须下沉到字节码层。
轻量级落地建议（不依赖 APM 框架）
若只需分析特定类的构造开销，可手动编写 transformer：
- 使用
ASM库解析并修改<init></init>方法：在方法首部插入visitMethodInsn(INVOKESTATIC, "MyMonitor", "onInitStart", "(Ljava/lang/Class;)V", false) - 在每个
RETURN和ARETURN前插入visitMethodInsn(INVOKESTATIC, "MyMonitor", "onInitEnd", "(Ljava/lang/Class;J)V", false)，传入类名和耗时纳秒值 -
MyMonitor类用ConcurrentHashMap<class atomiclong></class>累计调用次数与总耗时，定期 dump 到日志或内存快照 - 启动时加参数：
-javaagent:instrument-agent.jar，确保 MANIFEST.MF 含Premain-Class和Can-Retransform-Classes: true
结合诊断工具快速验证
不想从零写 ASM？可用现成工具辅助定位热点：
- 用
jcmd <pid> VM.native_memory summary</pid>查看堆外内存趋势，辅助判断是否构造引发频繁分配 - 开启 JVM 参数
-XX:+PrintGCDetails -Xlog:gc+allocation=debug（JDK 11+），观察对象分配栈（Allocation Stall） - 配合
async-profiler录制-e alloc事件，直接看到哪些<init></init>调用分配最多内存 - 这些数据可交叉验证字节码增强采集的结果，避免误判“慢构造”是 GC 延迟导致的假象
