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