jmap -histo用于快速筛查堆中类实例数量是否异常，输出实例数、总字节及类名，响应快、开销低，适合生产环境初步定位代理类（如$proxy、mapperproxy）是否突增，但无法显示引用关系，需结合jmap -dump与mat进一步分析泄漏根因。
用 jmap -histo 看类实例数量是否异常
jmap -histo 输出的是当前堆中所有类的实例数、总大小和平均大小，不生成完整 dump，响应快、开销低，适合在生产环境快速筛查。它不能替代 jmap -dump，但能帮你 10 秒内回答：“是不是某类对象突然多了几百倍？”
执行命令后重点关注三列：num（实例数）、bytes（总字节）、class name（类名）。动态代理类通常有固定命名模式，比如：
-
com.sun.proxy.$Proxy*（JDK 动态代理） -
org.springframework.cglib.proxy.Enhancer$EnhancerKey*或net.sf.cglib.core.KeyFactory$KeyFactoryImpl（CGLib） -
org.apache.ibatis.binding.MapperProxy*（MyBatis）
如果某类匹配上述模式且 num 值远高于其他业务类（例如 >5000，而普通 POJO 多为个位数或几十），就值得怀疑。
为什么不能只看类名匹配？得结合生命周期判断
仅靠类名匹配会误报。比如 Spring Boot 启动时 CGLib 会生成少量代理类，这是正常的；但若应用运行 2 小时后，$Proxy123 实例从 2 个涨到 3800 个，且伴随 ThreadLocal 或静态集合引用，才是泄漏信号。
关键要确认两点：
- 该类是否本应“一次性创建、长期复用”？如果是，实例数应基本稳定；若持续增长，说明代理工厂被反复调用且未缓存
- 是否与线程池/请求生命周期耦合？比如每次 HTTP 请求都 new 一个
MapperProxy，但没走 Spring 容器管理，就会堆积
此时建议立刻补查：jstat -gc <pid></pid> 看老年代使用率是否同步爬升，以及 jstack <pid> | grep -A5 -B5 Proxy</pid> 看哪些线程正在构造这类对象。
对比 histo 和 dump 的定位精度差异
jmap -histo 只告诉你“有多少”，不告诉你“谁在引用它”。比如发现 $Proxy456 有 2100 个实例，但无法知道它们是被某个 static ConcurrentHashMap 持有，还是被 ThreadLocal 绑定在 2100 个线程里。
这时候必须升级动作：
- 先用
jmap -dump:live,format=b,file=heap.hprof <pid></pid>抓一份带存活对象的 dump（加live避免包含待回收垃圾） - 再用 MAT 打开，按 class 名过滤，右键 → “Merge Shortest Paths to GC Roots” 查引用链
- 特别注意路径中是否出现
java.lang.ThreadLocal$ThreadLocalMap或static字段 —— 这才是真正的泄漏根因
跳过这步直接改代码，大概率修了表象、漏了根源。
容易被忽略的陷阱：类名模糊匹配失效
某些代理类名会被混淆或截断。例如在 JDK 17+ 或开启 Class Data Sharing（CDS）时，jmap -histo 可能显示 com.sun.proxy.$P* 而非完整名；又或者 Spring AOP + GraalVM native image 下，代理类根本不出现在 histo 列表里。
遇到匹配不到但内存仍在涨的情况，别硬盯 histo，换思路：
- 用
jcmd <pid> VM.native_memory summary.diff</pid>确认是不是 Metaspace 在涨（说明类加载异常） - 加 JVM 参数
-XX:+TraceClassLoading -XX:+TraceClassUnloading观察是否有高频 load/unload - 检查是否用了
new ProxyGenerator().generateProxyClass()这类手动生成方式 —— 它绕过了 Spring 的代理缓存机制
真正难排查的，从来不是“有没有代理类”，而是“为什么这个本该缓存的代理，每次都在重建”。
