循环调用Jsoup.connect().get()时触发JVM致命SIGSEGV错误

你遇到的这个**SIGSEGV（段错误）**是JVM层面的致命崩溃，不是普通的Java异常。从错误栈来看，问题出在并行垃圾回收的晋升管理器（PSPromotionManager）复制对象到Survivor区时出错，通常和JVM版本bug、内存压力或者资源泄漏有关。下面给你几个具体的排查和解决步骤：

1. 优先升级JVM版本 #

你当前使用的是Java 8u181，这是2018年的老版本，存在不少已知的GC相关稳定性bug。建议直接升级到Java 8的最新补丁版本（比如u381），或者更推荐升级到Java 11/17这类LTS长期支持版本——新版本修复了大量旧版JVM的底层问题，很多类似的GC崩溃都能通过升级直接解决。

2. 优化Jsoup的循环使用方式 #

循环中频繁调用Jsoup.connect("myurl").get()可能引发内存压力过载，进而触发GC时的崩溃：

• 确保每次获取的doc对象在使用后没有被意外持有引用（比如存进全局集合却没及时清理），否则会导致对象无法被回收，老年代内存持续膨胀，GC负担急剧增加。
• 复用Jsoup的Connection实例，避免每次循环都新建连接对象：

  Connection conn = Jsoup.connect("myurl");
  for (...) {
      Document doc = conn.get();
      // 处理doc逻辑
  }
  

• 添加超时配置，避免请求阻塞导致线程堆积：

  doc = Jsoup.connect("myurl").timeout(5000).get();
  

3. 分析崩溃日志与核心转储 #

生成的hs_err_pid12495.log文件里有更详细的崩溃上下文，你可以重点关注：

• Physical Memory Usage部分，确认是否存在系统内存不足的情况。
• Current Thread和Stack Trace部分，看是否能关联到特定业务代码，排查是否是某类特殊请求触发的崩溃。
  如果有核心转储文件，还可以用jstack工具分析线程状态，或者用jmap查看内存对象分布，确认是否有异常的对象堆积。

4. 调整JVM GC参数（临时排查手段） #

如果暂时无法升级JVM，可以尝试调整GC参数规避问题：

• 增大Survivor区的大小，减少对象晋升到老年代的频率：-XX:SurvivorRatio=6（默认值是8，数值越小Survivor区占比越大）。
• 尝试禁用Compressed Oops（该选项在部分老版64位JVM上存在兼容性bug）：-XX:-UseCompressedOops，注意这会增加内存占用，仅作为临时排查使用。

5. 升级Jsoup版本 #

虽然Jsoup是纯Java库，但旧版本可能存在一些内存管理细节上的问题，建议升级到最新稳定版，排除库本身的潜在隐患。

内容的提问来源于stack exchange，提问作者Shubham Sharma