优先用jstack + top -H（Linux）或VisualVM采样器；前者秒级获取高CPU线程堆栈，后者零配置实时显示热点方法；JProfiler适合已锁定问题后的深度分析。
Java应用CPU飙升时，该先用哪个工具定位？
别急着开JProfiler——它启动重、侵入强，适合深度调优而非快速排查。优先用jstack + top -H（Linux）或VisualVM自带的采样器：前者能秒级抓到占用CPU最高的线程ID并导出堆栈，后者零配置、实时显示热点方法。JProfiler更适合已锁定可疑模块后，分析对象生命周期、锁竞争或GC行为。
JProfiler连接本地Java进程失败的常见原因
不是授权问题，多数是JVM启动参数没配对。JProfiler默认用libjprofilerti.so（Linux/macOS）或jprofilerti.dll（Windows）做Agent注入，必须在java命令中显式添加：
-agentpath:/path/to/jprofiler/bin/linux-x64/libjprofilerti.so=port=8849。注意三点：
- 路径必须绝对，不能用
~或环境变量 -
port值要和JProfiler GUI里“Session Settings → Connection → Port”一致 - 如果JVM启用了
SecurityManager或容器限制了ptrace（如Docker默认），会
静默失败
对比Arthas、Async-Profiler与JProfiler的适用边界
它们根本不是同一类工具：
-
Arthas：线上诊断利器，支持运行时热插拔、方法级trace、动态修改变量，但不提供图形化内存快照 -
async-profiler：无侵入、低开销的火焰图生成器，擅长CPU/Alloc/lock事件采样，输出flamegraph.html，但无法交互式钻取对象引用链 -
JProfiler：全功能商业工具，强在内存泄漏分析（可对比两次heap dump的diff）、线程状态可视化、数据库SQL耗时归因，代价是必须预埋Agent且影响吞吐
JProfiler中“Live Memory”视图里对象数量不准？
这是常见误解——Live Memory显示的是JProfiler Agent从启动后累计分配的对象数，不是当前堆内存活对象。真正反映内存压力的是Heap Walker里的Classes视图，它基于完整heap dump解析，能精确统计每个类的实例数、浅堆/深堆大小。若发现某类实例数持续增长但GC后不降，再用Reference Chains查谁在强引用它。切记：不要依赖Live Memory判断内存泄漏，它连GC都绕过。
