Java 报错分析提示词（异常堆栈定位、OutOfMemoryError 分类排查、线程 dump 看死锁与线程池打满）
Java 服务报了一长串异常堆栈看不懂、出现 OutOfMemoryError、接口全部卡住疑似死锁或线程池耗尽时用：把堆栈、GC 日志或线程 dump 贴给 AI，它找出真正的根因所在行、判断 OOM 属于哪一类，并告诉你下一步该抓什么数据、怎么修。
通用大模型 对话模型通用
你是一名排查过大量 Java 线上问题的工程师，熟悉 JVM 内存结构、GC 和线程模型。请帮我分析下面的问题。 - 问题类型：[问题类型]（可选：异常堆栈/内存溢出/接口卡死） - JDK 版本与框架：[JDK 与框架]（例：JDK 17 + Spring Boot 3） - JVM 启动参数：[JVM 参数]（例：-Xmx2g，没有就写不知道） - 部署环境：[部署环境]（例：容器内存限制 3G） - 现象与发生时间：[现象] - 材料（异常堆栈、GC 日志片段、线程 dump，原样粘贴）： [粘贴材料] - 相关代码（如果已经定位到某个类）： [相关代码] 分析方法： 1. 异常堆栈： - 找到最底层的 Caused by，这通常才是根因； - 跳过框架内部的调用帧，找出第一个属于我们自己代码的帧，指出具体的类、方法和行号； - 解释异常的直接原因（比如空指针是哪个变量为空），以及可能的上游原因。 2. 内存溢出：先根据错误信息判断类型——堆内存不足、元空间不足、无法创建新的本地线程、直接内存不足、GC 开销超限、容器限制导致进程被系统终止（这种情况 JVM 可能来不及打印错误）——不同类型的排查方向完全不同。然后说明需要的数据（堆转储、GC 日志）、启动参数应该怎么加，以及分析堆转储时看什么。 3. 线程 dump：统计线程状态分布；找出大量线程阻塞在同一处的位置（例如都在等待数据库连接池、都在等同一把锁）；检测死锁（dump 中会明确标出）；判断是线程池满了还是下游变慢。 4. 给出结论：最可能的根因（按可能性排序）、验证方法、修复方案、短期止血办法。 材料不足以下结论时，告诉我还需要哪些数据、用什么命令获取。
高亮处换成你自己的内容：[问题类型]、[JDK 与框架]、[JVM 参数]、[部署环境]、[现象]、[粘贴材料]、[相关代码]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[粘贴材料] 不要只截取最上面几行。异常堆栈要包含所有 Caused by 段；线程 dump 最好完整贴上，或者至少包括所有业务线程。[部署环境] 中的容器内存限制很重要，堆设置得太接近容器限制时，进程会被直接终止，日志里看不到 OOM。
常见坑：
- 只看堆栈最上面一行，那往往是框架包装后抛出的异常，真正的原因在最下面的 Caused by。
- 一遇到 OOM 就调大堆内存，如果是内存泄漏，只是推迟了崩溃时间；如果是「无法创建本地线程」，调大堆反而更糟。
- 线上卡住时只重启不留证据。重启前先抓一次线程 dump（间隔几秒抓两到三次），之后才有机会找到原因。
追问技巧：拿到堆转储的分析结果（如占用最多的对象、支配树）后贴回去，问「这些对象被谁持有，对应哪段代码」。
示例输出
示例，仅供参考（线程 dump，接口全部超时）
线程状态：200 个 Tomcat 工作线程中，186 个处于 TIMED_WAITING，堆栈均停在：
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:...)
at ...OrderRepository.findByUser(OrderRepository.java:42)判断：线程池满的直接原因是数据库连接池耗尽（连接池大小为 10，所有线程都在等连接），而不是死锁（dump 中没有死锁提示）。
可能的根因（按可能性）：
- 有慢查询长时间占用连接——查看同时段数据库的慢查询日志；
- 连接泄漏——代码中手动获取连接后未在异常路径关闭，开启连接池的泄漏检测验证；
- 下游流量突增——对比请求量监控。
止血：临时扩容实例分摊流量；定位到慢查询后先加索引或限流该接口。不建议直接把连接池调得很大，会把压力转移给数据库。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～