OA 系统假死问题分析与优化
一、现场环境详情
应用环境
JDK 版本：open-jdk_1.8.0_312
应用服务器：TongWeb7049M3（主从节点部署 + 负载代理）
JVM 初始配置：最大 / 最小堆内存 8192m，元空间 512M，最大线程数 2000
二、问题现象
2025 年 12 月至 2026 年 1 月初，港航水利 OA 系统多次出现无响应状态，用户无法正常登录、操作各类业务模块，系统完全卡死。每次故障发生后，需通过重启 TongWeb 应用服务器才能恢复服务，严重影响日常办公与业务推进。
三、根因分析
通过提取系统日志、分析内存镜像文件（heap.hprof），结合应用代码排查，定位问题核心原因如下：
（一）内存占用异常触发溢出
应用安全检测模块存在高内存消耗漏洞，具体表现为：
1、系统安全模块（weaver.security.core.SecurityCore、weaver.security.classLoader.ReflectMethodCall）需对数据库大量请求文本执行 XSS/SQL 注入检测；
2、检测过程中通过正则匹配实现安全校验，但未对Matcher对象进行复用，单次请求瞬间创建海量临时Matcher对象；
3、海量Matcher对象快速占用 JVM 堆内存，导致内存资源耗尽；
4、JDK 垃圾回收机制无法及时回收临时对象，最终引发内存溢出（OOM），系统资源耗尽后出现假死。
（二）核心内存占用对象统计
通过内存镜像分析工具（Eclipse MAT）排查，关键内存占用对象如下表所示：
内存占比 核心占用对象 关联模块 说明
17.78% net.sf.ehcache.store.chm.SelectableConcurrentHashMap 缓存模块 缓存分段存储结构，占用大量堆内存
19.88% weaver.monitor.cache.CacheFactory 系统监控缓存 监控缓存哈希表，长期运行未清理导致堆积
（三）内存镜像关键截图说明
上图SelectableConcurrentHashMap 相关对象内存占用详情
缓存模块的分段存储对象（SelectableConcurrentHashMap$Segment）累计占用 17.78% 内存，单段对象内存占用约 6MB，共 19128 个相关对象，存在缓存堆积问题。
上图系统监控缓存内存占用详情
weaver.monitor.cache.CacheFactory 关联的 ConcurrentLinkedHashMap 占用 19.82% 内存，哈希表节点（ConcurrentHashMapV8$Node）数量庞大，未有效清理过期缓存。
四、优化调整方案
（一）JVM 参数优化
针对内存溢出问题，调整 TongWeb 容器 JVM 配置，提升内存容量与垃圾回收效率，具体参数调整如下：
参数名称 原配置 新配置 优化目的
-Xms（初始堆内存） 8192m 16384m 扩大初始堆内存，避免频繁内存扩容
-Xmx（最大堆内存） 8192m 16384m 提升最大堆内存上限，减少内存溢出概率
-XX:MaxMetaspaceSize（最大元空间） 512m 2048m 增加元空间容量，适配多类加载场景
-XX:CompileThreshold 默认值 100000 方法调用达 10 万次时编译为机器码（仅 Client 模式有效），提升执行效率
-XX:+DisableExplicitGC 未配置 启用 禁用代码中手动调用的 System.gc ()，避免触发 Full GC 导致系统卡顿
五、后续监控与长期建议
（一）短期监控动作
1.高并发时段监控：业务高峰时段登录 TongWeb 监控面板，重点查看内存使用率、线程状态、请求响应时间，确保各项指标正常；
2.内存占用排查：当系统出现响应缓慢时，执行命令 top -H -p TongWeb进程号，查看线程 CPU 与内存占用详情，定位异常线程；
3.线程栈分析：定期执行线程栈打印命令 jstack TongWeb进程号 > 1.txt，分析线程运行状态，排查阻塞线程；
4.日志分析：每日查看 JVM 日志与 GC 日志，关注是否存在频繁 Full GC、内存持续攀升等异常情况。
（二）长期优化建议
1.安全模块代码优化：与泛微开发团队沟通，优化weaver.security.core.SecurityCore模块的正则匹配逻辑，实现Matcher对象复用，减少临时对象创建；
2.缓存策略调整：针对 ehcache 缓存与系统监控缓存，配置合理的缓存过期时间与最大容量，避免缓存长期堆积占用内存；
3.压力测试验证：优化后开展高并发压力测试，模拟峰值流量场景，验证系统稳定性与内存占用情况；