JVM Crash的几个实例

最新推荐文章于 2025-04-21 14:31:33 发布
原创 最新推荐文章于 2025-04-21 14:31:33 发布 · 5.6k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#crash #jvm #generation #java #thread #report

本文记录了三起JVM Crash实例的排查过程，包括通过hs_err_pid.log文件定位潜在的JVM bug，调整-Xss参数解决jboss启动时的段错误问题，并提供了core.pid文件的分析方法。
部署运行你感兴趣的模型镜像

最近遇到几个JVM Crash的实例，一共三起，其中一起确定原因，也解决了，其它的还只能猜测可能的原因！

一、JVM 运行一段时间之后突然Crash，生成的hs_err_pid.log文件部分内容如下：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b42ca9e64f0, pid=14881, tid=1092757824
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 )
# Problematic frame:
# V  [libjvm.so+0x5c04f0]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00000000499ee800):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=14905, stack(0x0000000041122000,0x0000000041223000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000000000000002c

Registers:
RAX=0x00002aab2ab21f40, RBX=0x0000000000000183, RCX=0x00002aab2a097e90, RDX=0x0000000000000008
RSP=0x000000004121e898, RBP=0x000000004121ead0, RSI=0x00002aab29f6d8c0, RDI=0x0000000000000000
R8 =0x0000000000001098, R9 =0x00002aab29373da0, R10=0x00002aab28eb06a0, R11=0x00002aab2ab21f70
R12=0x000000004121f798, R13=0x0000000000000052, R14=0x0000000000000000, R15=0x00002aab2a9e2ff0
RIP=0x00002b42ca9e64f0, EFL=0x0000000000010202, CSGSFS=0x000000000000e033, ERR=0x0000000000000004

通过google，推测可能是JVM的一个bug，但不能确定：http://www.oracle.com/technetwork/java/javase/crashes-137240.html#gbyzd

二、JVM运行一段时间之后突然Crash，生成的hs_err_pid.log文件如下：

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b624490ac98, pid=2191, tid=1107622208
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x5e9c98]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x000000004b8c4000):  GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=2197]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000

Registers:
RAX=0x000000000d0e8cad, RBX=0x0000000789ddf538, RCX=0xf13bc057f13bc04c, RDX=0x0000000000000001
RSP=0x000000004204e820, RBP=0x000000004204e880, RSI=0x00002aaac0cf7120, RDI=0x000000004b8caf40
R8 =0xf13bc057f13bc04e, R9 =0x00000007d96af400, R10=0x0000000000000010, R11=0x0000000000000011
R12=0x0000000000000000, R13=0x000000000d0e8cad, R14=0x000000004b8caf40, R15=0xf13bc057f13bc04e
RIP=0x00002b624490ac98, EFL=0x0000000000010282, CSGSFS=0x0000000000000033, ERR=0x0000000000000000
  TRAPNO=0x000000000000000d
……
Heap
 par new generation   total 471872K, used 435920K [0x0000000770000000, 0x0000000790000000, 0x0000000790000000)
  eden space 419456K, 100% used [0x0000000770000000, 0x00000007899a0000, 0x00000007899a0000)
  from space 52416K,  31% used [0x000000078ccd0000, 0x000000078dce4000, 0x0000000790000000)
  to   space 52416K,  74% used [0x00000007899a0000, 0x000000078bfcff20, 0x000000078ccd0000)
 concurrent mark-sweep generation total 1572864K, used 1223031K [0x0000000790000000, 0x00000007f0000000, 0x00000007f0000000)
 concurrent-mark-sweep perm gen total 262144K, used 67047K [0x00000007f0000000, 0x0000000800000000, 0x0000000800000000)
通过google，推测可能是JVM的一个bug，但因为不能稳定重现，也不能确定： http://bugs.sun.com/view_bug.do?bug_id=6896647


三、jboss启动时，提示段错误，然后进程就crash了，在目录下生成了core.pid文件。

之前一直没有core.pid文件生成，折腾了比较久，启动时通过jmx连接来看，在crash之前的CPU和内存均看不出异常，而且crash了之后什么信息也没留下，因此一愁莫展！

后来有一位同学经过一阵努力，使得它可以在crash之前生成core.pid文件了，这个文件生成的head dump文件没看出异常，但是生成的堆栈信息里有一个堆栈长度特别长，联想到我们的-Xss=256k参数，以及之前由于这个参数出现过内存溢出现象。于是将这个参数改为1024k解决问题！具体原因见：

http://www.oracle.com/technetwork/java/javase/crashes-137240.html#gbyzz

对于core.pid文件，有几种方法可以分析：1.可以通过jmap生成heap dump文件；2.可以使用jstack查看crash时的堆栈信息；3.可以使用gdb查看crash时正在执行的代码等等。

您可能感兴趣的与本文相关的镜像

LobeChat

LobeChat

AI应用

LobeChat 是一个开源、高性能的聊天机器人框架。支持语音合成、多模态和可扩展插件系统。支持一键式免费部署私人ChatGPT/LLM 网络应用程序。

zhangren07
关注
java进阶篇--生产环境如何排查bug和优化 JVM？
爱分享的淘金达人
06-22 1114
通过前面几个课时的学习，相信你对 JVM 的理论及实践等相关知识有了一个大体的印象。而本课时将重点讲解 JVM 的排查与优化，这样就会对 JVM 的知识点有一个完整的认识，从而可以更好地应用于实际工作或者面试了。 我们本课时的面试题是，生产环境如何排查问题？ 回答： 如果是在生产环境中直接排查 JVM 的话，最简单的做法就是使用 JDK 自带的 6 个非常实用的命令行工具来排查。它们分别是：jps、jstat、jinfo、jmap、jhat 和 jstack，它们都位于 JDK 的 bin 目录下，可
jvm排查问题-实践追踪问题 与思路--堆内堆外内存泄漏排查方针
凌波漫步
12-26 1432
JDK默认使用G1GC算法，G1将堆内存划分为等大的Region，并逐一选取可用的Region分配对象。一个对象的Size超过Region大小的一半则被称为大对象（Humongous），G1会将大对象独立放在一个或连续多个Region中。独立分配/回收大对象的成本比较低，不需要和其它小对象公用Region；存放大对象的Region放在独立的区域中，存活的大对象不会被GC Copy，介绍了GC开销；
JVM触发崩溃的简单脚本
热干面先拌拌的博客
04-21 154
【代码】JVM触发崩溃的简单脚本。
jvm实例的个数
weixin_34406061的博客
12-16 411
Generally speaking, each application will get its own JVM instance and its own OS-level process and each JVM instance is independent of each other. There are some implementation details such as Cla...
大对象导致JVM Crash (Jboss) 分析及解决 - JDK 已知bug
weixin_33724059的博客
11-30 203
From：http://www.javaeye.com/topic/799952 最近在一个项目中，web应用跑一段时间后, JBoss JVM crash，web日志中没有任何异常。 存放日志的地方发现有hs_err_pid25052.log，发现这个文件，就知道是JVM crash了。 打开这个文件然后分析： Log代码 ...
Android问题笔记四十二：signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) 的解决方法
空名先生
10-28 4024
之前开发的 SO 一直很正常，最近一段时间有新业务要在原来SO 上开发，并且有了新的设计逻辑，也是新的同事去写了。所以公司准备 SO 重写一下。部分业务还是仿照或复制原来的代码，但是给到 Android 后一直崩溃，而且看 JNI 中同事写的日志最终停止点不固定。
大对象导致JVM Crash (Jboss) 分析及解决
weixin_34144848的博客
11-09 197
转载http://www.javaeye.com/topic/799952 最近在一个项目中，web应用跑一段时间后, JBoss JVM crash，web日志中没有任何异常。 存放日志的地方发现有hs_err_pid25052.log，发现这个文件，就知道是JVM crash了。 打开这个文件然后分析： ---------------...
java jvm崩溃_你如何崩溃JVM？
weixin_36399446的博客
02-28 354
问题我正在读一本关于编程技巧的书，其中作者问受访者："你如何崩溃JVM？"我认为你可以通过编写一个最终耗尽所有内存的无限for循环来实现。有人有什么想法吗？#1 热门回答(162 赞)我不会调用抛出OutOfMemoryError或StackOverflowError崩溃。这些只是正常的例外。要真正崩溃VM有三种方法：使用JNI并在本机代码中崩溃。如果未安装安全管理器，则可以使用反射来崩溃VM。这...
java crash 日志分析_Java JVM Crash 日志文件分析
weixin_31526891的博客
03-04 1081
Java的应用有时候会因为各种原因Crash，这时候会产生一个类似java_errorpid.log的错误日志。可以拿到了这个日志，怎样分析Crash的原因呢？下面我们来详细讨论如何分析java_errorpid.log的错误日志。一. 如何得到这个日志文件如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。缺省情况下，这个文件会产生在工作目录下。但是，可以...
JVM内存问题排查
偶尔写些东西，意思一下我也参与了内卷
01-25 1578
JVM 的堆空间分成2个区域：年轻代、老年代年轻代又进一步细分成3个区域：Eden、Survivor From、Survivor To。
jvm故障 内存泄露和内存溢出总结
许诗宇的博客
01-28 3096
注意：本文参考 JAVA内存泄漏和内存溢出的区别和联系_weixin_34292402的博客-优快云博客 引起Java中内存泄露8种场景归纳，一定要避开这些！_公众号:肉眼品世界的博客-优快云博客 内存泄漏memory leak 当某些对象不再被应用程序所使用,但是由于仍然被引用，而导致垃圾收集器不能释放(Remove,移除)他们。程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。 内存泄漏的分类（按发生方式来分类） 1 常发性..
关于编写Java程序让Jvm崩溃
CSDnjava001的博客
05-23 494
在书上看到一个作者提出一个问题“怎样通过编写Java代码让Jvm崩溃”，我看了之后也不懂。带着问题查了一下，百度知道里面有这样一个答案： 1 package jvm; 2 3 public class Crash { 4 public static void main(String[] args) { 5 6 //Object[] o = {“abc”};初始值赋值，不会有...
jvm crash 的原因以及解决办法
大漠孤狼的博客
07-11 1万+
java内存 JVM 虚拟机 hs_err_pid
jvm crash,疑似GC的bug
幸福的懦夫
11-18 567
在对一个应用做压力的时候，不定时发生jvm crash，查看hs_error.log 内容摘要如下： Current thread (0x0000000051f8f800): GCTaskThread [stack: 0x00000000413c2000,0x00000000414c3000] [id=15399] Heap PSYoungGen total 3482...
年轻代gc jvm crash
lovewendy19860402的专栏
07-31 593
最近公司线上部分服务器出现了gc异常崩溃，检查了下异常崩溃日志，但是应用日志并没有出现很大的异常，但是在日志文件系统发现了hs_err_pid32506.log日志，这基本判定是jvm 异常了 打开日志文件   当时线程崩溃的是GCTaskThread   这个是当时所有Thread的列表，执行的线程exited是GCTaskThread  这块就发现是eden区域满了的时候发生了异常...
JVM Crash的定位和解决办法
sutonline的博客
06-08 3074
JVM的Crash定位及解决办法
Android NDK开发崩溃signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) 的解决方法
相忘于江湖
10-10 5万+
一.前言 在NDK开发的过程中，如果遇到应用Crash的情况，JNI层的报错信息并不像java层那样可以直接看到错误信息和错误的位置，如果要想定位的到错误的位置，需要借助NDK的一些工具进行地址转换，本文中用addr2line（NDK的工具）来捕捉错误信息 二.分析 以下是我的报错信息 读取其中的关键信息 1.错误代号：signal 11 (SIGSEGV), cod...
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
qq_24131317的博客
08-19 2644
Android 10 华为手机运行原生app报错： Timestamp: 2021-08-19 09:58:05+0800 2021-08-19 09:58:05.940 A/DEBUG: pid: 7178, tid: 7227, name: LeakCanary-Heap >>> com.jjkj.sbdj <<< 2021-08-19 09:58:05.940 A/DEBUG: uid: 10465 2021-08-19 09:58:05.940 A/DEBUG:
JVM致命错误日志(hs_err_pid.log)分析
热门推荐
chenssy 的技术博客
10-18 11万+
最近两天测试环境有一个服务总是会挂（两到三天一次），JVM虚拟机总是会崩溃。所以有必要了解JVM崩溃的原因是什么。当JVM发生致命错误导致崩溃时，会生成一个hs_err_pid_xxx.log这样的文件，该文件包含了导致 JVM crash 的重要信息，我们可以通过分析该文件定位到导致 JVM Crash 的原因，从而修复保证系统稳定。默认情况下，该文件是生成在工作目录下的，当然也可以通过 JVM
package com.walmart.aloha.payment.core.pulsar.producer; import com.walmart.aloha.payment.core.constants.PayConstants; import lombok.extern.slf4j.Slf4j; import org.apache.pulsar.client.api.*; import org.springframework.beans.factory.DisposableBean; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; import org.springframework.stereotype.Component; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.TimeUnit; /** * Pulsar生产者工厂类，用于创建和管理Pulsar生产者实例。 */ @Component @ConditionalOnProperty( value = {"pulsar.enable"}, matchIfMissing = true ) @Slf4j public class PulsarProducerFactory implements DisposableBean { @Autowired private PulsarClient pulsarProducerClient; private final Map<String, Producer<String>> producerAndTopicMapping = new ConcurrentHashMap<>(); private static final boolean ENABLE_BATCHING = true; private static final CompressionType COMPRESSION_TYPE = CompressionType.LZ4; private static final int BATCHING_MAX_PUBLISH_DELAY_MS = 10; private static final int SEND_TIMEOUT_SECONDS = 20; private static final int BATCHING_MAX_MESSAGES = 1000; private static final int MAX_PENDING_MESSAGES = 1000; private static final boolean BLOCK_IF_QUEUE_FULL = true; private static final int ROUND_ROBIN_ROUTER_BATCHING_PARTITION_SWITCH_FREQUENCY_MS = 10; private static final BatcherBuilder BATCHER_BUILDER = BatcherBuilder.DEFAULT; @Value(value = "${pulsar.tenant.name}") private String pulsarTenantName; @Value(value = "${pulsar.namespace.name}") private String pulsarNamespaceName; /** * 创建Pulsar生产者实例。 * * @param topicName 主题名称 * @return Pulsar生产者实例 */ private Producer<String> createProducer(String topicName) { try { String topicNamePrefix = new StringBuilder("persistent://") .append(pulsarTenantName) .append(PayConstants.PATH_SEPARATOR) .append(pulsarNamespaceName) .append(PayConstants.PATH_SEPARATOR).toString(); log.info("消息中心--topic:{} 创建生产者", topicNamePrefix + topicName); return pulsarProducerClient.newProducer(Schema.STRING) .topic(topicNamePrefix + topicName) .enableBatching(ENABLE_BATCHING) .compressionType(COMPRESSION_TYPE) .batchingMaxPublishDelay(BATCHING_MAX_PUBLISH_DELAY_MS, TimeUnit.MILLISECONDS) .sendTimeout(SEND_TIMEOUT_SECONDS, TimeUnit.SECONDS) .batchingMaxMessages(BATCHING_MAX_MESSAGES) .maxPendingMessages(MAX_PENDING_MESSAGES) .blockIfQueueFull(BLOCK_IF_QUEUE_FULL) .roundRobinRouterBatchingPartitionSwitchFrequency(ROUND_ROBIN_ROUTER_BATCHING_PARTITION_SWITCH_FREQUENCY_MS) .batcherBuilder(BATCHER_BUILDER) .create(); } catch (PulsarClientException e) { log.error("消息中心--topic:{} 创建生产者失败", topicName, e); return null; } } /** * 获取或创建Pulsar生产者实例。 * * @param topicName 主题名称 * @return Pulsar生产者实例 */ private Producer<String> getProducer(String topicName) { return producerAndTopicMapping.computeIfAbsent(topicName, this::createProducer); } /** * 发送消息到指定主题。 * * @param topicName 主题名称 * @param msg 消息内容 * @return 消息ID */ public MessageId sendMessage(String topicName, String msg) { if (topicName == null || msg == null) { throw new IllegalArgumentException("Topic and message cannot be null"); } Producer<String> producer = getProducer(topicName); if (producer == null) { log.error("消息中心--topic:{} 获取生产者失败", topicName); return null; } MessageId messageId = null; try { messageId = producer.send(msg); } catch (PulsarClientException e) { log.error("同步消息--topicName :{} 消息发送失败", topicName, e); } if (messageId != null) { log.info("同步消息：topicName:{}, message:{} 发送成功, messageId:{}", topicName, msg, messageId); } else { log.error("同步消息：topicName:{}, message:{} 发送失败", topicName, msg); } return messageId; } @Override public void destroy() { producerAndTopicMapping.forEach((topicName, producer) -> { try { producer.close(); } catch (PulsarClientException e) { log.error("消息中心--topic:{} 关闭生产者失败", topicName, e); } }); producerAndTopicMapping.clear(); } } 这段代码会导致老年代内存升高吗
最新发布
10-28
这段 Java 代码是基于 **Apache Pulsar** 的生产者工厂类，用于创建和管理多个 Pulsar 生产者（`Producer<String>`），并通过 `ConcurrentHashMap` 缓存它们。你问的是：**这段代码会导致老年代内存升高吗？** --- ### ✅ 回答问题 **有可能导致老年代内存升高，但通常不会直接“泄漏”或“无限增长”，是否引起老年代内存持续升高取决于使用方式、主题数量、对象生命周期和 GC 行为。** 我们逐项分析可能导致老年代内存升高的原因： --- ## 🔍 潜在导致老年代内存升高的因素 ### 1. `producerAndTopicMapping` 是永久缓存（无过期/清理机制） ```java private final Map<String, Producer<String>> producerAndTopicMapping = new ConcurrentHashMap<>(); ``` - 使用了 `computeIfAbsent(topicName, this::createProducer)` 来缓存每个 topic 对应的 `Producer`。 - **一旦创建，永远不会移除**（除非应用关闭时调用 `destroy()`）。 - 如果系统中频繁地使用不同的 `topicName`（比如动态生成大量唯一 topic 名称），那么这个 map 会不断增长。 > 🚨 **后果**： > - `Producer` 实例本身包含大量资源（Netty 连接、线程引用、配置对象等），占用堆内存较多。 > - 长时间存活的对象会被晋升到 **老年代（Old Generation）**。 > - 如果 `topicName` 数量很大且不重复，map 中的 entry 和对应的 `Producer` 实例将长期驻留老年代，造成老年代内存持续上升。 --- ### 2. `Producer` 实例较重，生命周期长 Pulsar 的 `Producer` 不是一个轻量级对象： - 它维护与 broker 的 TCP 连接； - 包含缓冲区、定时器、批处理队列； - 内部状态复杂，占用内存较大。 这类对象一旦被创建并长期持有（如放入静态 map），很容易进入老年代。 --- ### 3. `@Value` 注入字段拼接 topic 前缀（潜在风险较小） ```java String topicNamePrefix = "persistent://" + pulsarTenantName + "/" + pulsarNamespaceName + "/"; ``` 这部分只是字符串拼接，影响小，但如果 topicName 拼出来错误或者有歧义，可能导致无意中创建了过多不同名称的 topic，间接导致更多 Producer 被创建。 --- ### 4. `destroy()` 方法实现了关闭逻辑 ✅ ```java @Override public void destroy() { producerAndTopicMapping.forEach((topicName, producer) -> { try { producer.close(); } catch (PulsarClientException e) { log.error("...", e); } }); producerAndTopicMapping.clear(); } ``` ✅ 在 Spring 容器销毁时会调用此方法，释放所有资源。 ⚠️ 但是：如果应用没有正常关闭（例如 crash 或 kill -9），这些资源不会释放。 --- ### 5. 是否启用批量发送、压缩等不影响内存区域，但影响对象大小 虽然设置了如下参数： ```java .enableBatching(ENABLE_BATCHING) .compressionType(COMPRESSION_TYPE) .batchingMaxMessages(BATCHING_MAX_MESSAGES) ... ``` 这些主要影响消息发送效率和网络传输，并不会显著增加堆内对象数量。但若消息积压严重，`maxPendingMessages` 可能导致待发送消息堆积，进而增加内存压力。 不过这里发送的是 `String` 类型，且通过 `send(msg)` 同步阻塞发送，积压可能性较低。 --- ## ✅ 总结：是否会引发老年代内存升高？ | 判断项 | 结论 | |-------|------| | 是否创建大量长期存活对象？ | ✅ 是（Producer 实例） | | 是否缓存永不删除？ | ✅ 是（Map 无清除策略） | | 是否可能因 topic 动态变化而膨胀？ | ⚠️ 视业务而定 —— 若 topic 是固定的几个，则安全；若动态生成无数个，则危险 | | 是否最终释放？ | ✅ 应用关闭时会释放（通过 `destroy()`） | | 是否容易 OOM 或 Full GC 频繁？ | ⚠️ 如果 topic 数量多且不变，可能引发老年代内存升高 → Full GC 频繁 | 👉 **结论：** > **如果 topicName 是有限、固定的集合（比如只有 payment-event、refund-event 等几个），则不会导致老年代内存异常升高。** > > **但如果业务允许传入任意或动态生成的 topicName（例如带时间戳、UUID、用户ID），就会导致 Producer 实例无限增长，最终使老年代内存不断升高，甚至触发 Full GC 或 OOM。** --- ## 💡 建议优化方案 ### ✅ 方案一：限制 topic 缓存数量 + 添加 LRU 缓存淘汰机制（推荐） 使用 `Caffeine` 或 `Guava Cache` 替代 `ConcurrentHashMap`，自动控制缓存大小： ```xml <!-- Maven --> <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>3.1.8</version> </dependency> ``` ```java import com.github.benmanes.caffeine.cache.Cache; import com.github.benmanes.caffeine.cache.Caffeine; // 替换原来的 ConcurrentHashMap private final Cache<String, Producer<String>> producerCache = Caffeine.newBuilder() .maximumSize(100) // 最多缓存 100 个生产者 .expireAfterAccess(30, TimeUnit.MINUTES) // 空闲 30 分钟自动关闭 .removalListener((String topic, Producer<String> producer, RemovalCause cause) -> { if (producer != null) { try { producer.close(); log.info("消息中心--topic:{} 已从缓存移除，原因: {}", topic, cause); } catch (PulsarClientException e) { log.error("关闭生产者失败", e); } } }) .build(); // 修改 getProducer 方法 private Producer<String> getProducer(String topicName) { return producerCache.get(topicName, this::createProducer); } ``` 这样可以防止无限缓存，避免老年代膨胀。 --- ### ✅ 方案二：校验 topicName 的合法性 & 白名单机制 在 `sendMessage()` 中加入校验： ```java Set<String> ALLOWED_TOPICS = Set.of("payment-event", "refund-event", "notification"); public MessageId sendMessage(String topicName, String msg) { if (!ALLOWED_TOPICS.contains(topicName)) { throw new IllegalArgumentException("Invalid topic name: " + topicName); } // ... } ``` 或者更灵活地使用正则匹配。 --- ### ✅ 方案三：监控老年代 GC 情况 建议开启 JVM 监控： ```bash -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log ``` 观察是否有频繁的 Full GC，配合 JConsole / VisualVM 查看老年代使用趋势。 --- ## ❓相关问题
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值