jstack可快速定位死锁，关注“Found 1 deadlock”及线程持锁/等待锁关系；jmap用于内存分析，结合-histo与-dump交叉验证线程阻塞与对象泄漏；应按jstack→jmap -histo→jmap -dump顺序及时采集带时间戳的快照。

用 jstack 快速定位死锁线程

死锁发生时，Java 应用通常表现为部分请求卡住、响应变慢，但 CPU 占用未必高。此时执行 jstack 能直接输出所有线程的堆栈快照。重点关注输出末尾的 “Found 1 deadlock” 提示——它会明确列出涉及死锁的线程、各自持有的锁、以及正在等待的锁。

例如，若看到两个线程分别持有 LockA 等待 LockB，另一个持有 LockB 等待 LockA，基本可确认是经典循环等待型死锁。注意：jstack 需在应用仍在运行（未假死）时及时抓取，否则可能错过现场。

用 jmap 定位内存异常增长源头

当怀疑内存溢出（如 OOM-Heap Space）时，先用 jmap -heap 查看堆内存使用概况，确认老年代是否持续增长、GC 是否频繁失败。再用 jmap -histo:live 获取实时存活对象统计，重点关注数量多或总大小异常高的类（比如大量 HashMap$Node、自定义缓存对象、未关闭的连接池对象等）。

若需进一步分析，可用 jmap -dump:format=b,file=heap.hprof 生成堆转储文件，配合 VisualVM 或 Eclipse MAT 打开，按“支配树（Dominators Tree）”查看谁持有了最多内存，常能发现静态集合类、监听器未注销、ThreadLocal 泄漏等问题。

arcgis-js

提供 ArcGIS Maps SDK for JavaScript 开发辅助，涵盖 2D/3D 地图视图、图层管理、数据可视化、空间分析等功能模块的参考和示例指导。

下载

将 jstack 与 jmap 结果交叉验证

单看线程或内存快照都容易误判。真正高效的方式是联合分析：

• 从 jstack 中标记出长期处于 WAITING 或 BLOCKED 的线程，记录其线程 ID（nid）和堆栈中的关键类名；
• 在 jmap -histo 输出中搜索这些类名，看对应实例数是否异常偏高；
• 若某业务线程卡在数据库连接获取上（jstack 显示阻塞在 DataSource.getConnection()），同时 jmap 显示大量 PooledConnection 或 Statement 实例未释放，大概率是连接未 close 导致池耗尽；
• 若多个线程都在等待同一个锁对象（jstack 中 lock id 如 0x00000000c0a1b2c3），可在 jmap dump 文件中搜索该地址（MAT 中用 OQL 查询 select * from java.lang.Object where @objectid == "0x00000000c0a1b2c3"），反查是谁创建并长期持有该锁。

实战建议：把快照采集变成标准动作

不要等到服务完全不可用才动手。建议在监控告警触发（如 GC 时间突增、线程数超阈值、HTTP 超时率上升）后立即执行：

• 顺序很重要：先 jstack（秒级完成，无侵入），再 jmap -histo（毫秒级），最后考虑 jmap -dump（可能暂停应用几秒，慎用于生产高峰）；
• 保留时间戳：给每个快照文件命名带上时间，如 jstack_20240520_1423.pid，方便回溯；
• 避免重复 dump：jmap -dump 会触发 Full GC，若已在频繁 GC，可能加剧问题，优先用 -histo 初筛；
• 本地复现 + 代码审计：拿到快照线索后，结合调用栈中的方法名、行号，在代码中定位同步块、锁粒度、资源释放逻辑，比纯靠工具更可靠。

不复杂但容易忽略