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