文字大小: 大中小

tomcat 服务器问题排查及优化

服务器 2025-03-19 04:54:00

问题: tomcat 服务器内存占用过高，而查看快照时却发现使用的内存并不多，假设已排除 native 组件占用内存的问题。

首先确定服务器配置，主要是服务器内存的大小。
检查tomcat使用的回收器是否适合当前服务器配置

案例1:

服务器内存不超过4G，多核，使用G1回收器(tomcat 9默认G1)

服务器内存过小场景下 G1 回收器的局限性分析‌

‌1. 内存开销与 Region 机制冲突‌

‌Region 划分的最小单位限制‌：
G1 将堆划分为固定大小的 Region（默认约 1MB~32MB），当总内存较小时（如 4GB 以下），Region 数量过少，难以发挥其优先回收高价值区域的策略优势，导致内存碎片化和回收效率下降‌。
‌元数据占用比例过高‌：
G1 依赖 Remembered Set（RSet）和 Card Table 记录跨 Region 引用关系，这些元数据占用额外内存。在小内存场景下，元数据可能占用堆空间的 ‌5%~10%‌，加剧内存压力‌。

‌2. 预测模型与停顿控制失效‌

‌停顿时间模型依赖充足内存缓冲‌：
G1 的 ‌MaxGCPauseMillis‌（默认 200ms）通过动态调整回收 Region 数量控制停顿时间，但小内存下可回收 Region 数量不足，容易触发 Full GC，导致实际停顿时间远超预期‌。
‌并发标记阶段资源争抢严重‌：
小内存服务器通常 CPU 核心数较少，G1 的并发标记线程（默认占用 25% CPU）会加剧资源竞争，影响应用吞吐量‌。

‌3. 对比其他回收器的适用性‌

‌场景‌	‌G1‌	‌ParNew + CMS‌ / ‌Serial‌
‌内存占用‌	高（元数据 + Region 管理）‌	低（无复杂分区结构）‌
‌小堆回收效率‌	低（Region 不足，频繁 Full GC）‌	高（分代明确，回收直接）‌
‌巨型对象处理‌	支持（但小内存易触发 Full GC）‌	依赖老年代分配，易碎片化‌

结论

由于G1回收器对元数据使用比例较大，在内存低于4g配置的服务器上使用G1回收器，会使得元数据占据大量内存，且核心数较少的情况下，G1难以发挥优势，相反会带来资源浪费和加剧资源竞争,G1回收器建议在至少超过8G内存的服务器上使用，建议采用 Parallel 或者 Serial 回收器。

案例2:

服务器内存不超过2G ，双核，使用 Parallel 回收器。

在2G内存2核服务器上使用Parallel GC的局限性分析‌

‌1. 资源竞争严重，CPU利用率过高‌

‌并行线程抢占CPU资源‌：
Parallel GC依赖多线程并行执行垃圾回收（默认线程数与CPU核心数相同）‌。在2核环境下，GC线程与应用线程会直接争抢CPU资源，导致应用吞吐量下降‌。
‌自适应调整失效‌：
Parallel GC的 ‌-XX‌ 参数依赖充足CPU资源实现停顿时间控制，但2核环境下难以满足并发需求，导致停顿时间不可控‌。

‌2. 内存不足引发频繁Full GC‌

‌堆内存分配受限‌：
2G内存下，需划分年轻代（Eden+Survivor）和老年代。若年轻代过小（如默认占比40%），对象快速晋升老年代，频繁触发Full GC‌。
‌内存碎片化加剧‌：
Parallel GC的标记-清除算法在内存不足时易产生碎片，进一步降低可用内存空间，触发更频繁的GC‌。

‌3. 对比其他回收器的适用性‌

‌场景‌	‌Parallel GC‌	‌Serial GC‌
‌CPU资源‌	要求高（多线程并行）‌	要求低（单线程）‌
‌内存压力‌	易触发Full GC‌	单线程GC减少内存争抢‌
‌停顿时间控制‌	不可控（2核下自适应失效）‌	停顿长但稳定（适合低负载场景）‌

‌

结论

由于Parallel 回收器依赖多线程炳辉执行，在2核环境下，GC线程与应用线程会直接争抢CPU资源，导致应用吞吐量下降‌，内存过低，导致频繁触发FGC，且容易产生碎片，加剧内存紧张的情况，建议使用 Serial 回收器。

G1 回收器适用的最佳配置指南

‌一、核心参数配置‌

‌启用G1回收器‌
- -XX:+UseG1GC：强制启用G1垃圾回收器‌。
‌堆内存与分区设置‌
- ‌堆大小‌：建议堆内存≥4GB，且初始堆与最大堆设为相同值（-Xms4g -Xmx4g），避免动态调整引发性能波动‌。
- ‌Region大小‌：通过-XX:G1HeapRegionSize指定（如-XX:G1HeapRegionSize=4m），需为1MB~32MB且是2的幂。默认由JVM根据堆大小自动计算‌。
‌并行线程与并发优化‌
- -XX:ConcGCThreads=<N>：设置并发标记阶段线程数，建议为CPU核心数的1/4（如4核设为1~2）‌。
- -XX:ParallelGCThreads=<N>：设置并行回收线程数，默认与CPU核心数相同（如4核设为4）‌。
‌停顿时间与回收触发阈值‌
- -XX:MaxGCPauseMillis=<N>：设定目标最大停顿时间（默认200ms），建议根据业务需求调整（如100~300ms）‌。
- -XX:InitiatingHeapOccupancyPercent=<N>（IHOP）：老年代占用率阈值，默认45%。高内存压力场景可降低至35%~40%以提前触发混合回收‌。
‌特殊场景优化‌
- ‌巨型对象处理‌：启用-XX:G1EagerReclaimHumongousObjects加速大对象回收，避免内存碎片‌。
- ‌RSet（记忆集）调优‌：通过-XX:G1RSetUpdatingPauseTimePercent限制RSet更新耗时占比（默认10%）‌。

二、适用场景与硬件要求

‌

‌场景类型‌	‌推荐配置‌	‌硬件要求‌
‌低延迟服务端应用‌	`-XX:MaxGCPauseMillis=100` + `-XX:ConcGCThreads=2` + 大Region（8MB~16MB）	CPU≥4核，内存≥8GB‌。
‌大内存批处理任务‌	默认参数 + `-XX:InitiatingHeapOccupancyPercent=35`	CPU≥8核，内存≥16GB‌。
‌混合负载场景‌	`-XX:G1MixedGCCountTarget=8`（混合GC次数） + 动态调整Region大小	内存≥4GB，CPU≥2核‌。

三、优化建议与避坑指南‌

‌避免频繁Young GC‌：
- 增大年轻代占比（-XX:G1NewSizePercent/-XX:G1MaxNewSizePercent），减少晋升压力‌。
- 监控晋升速率，若老年代增长过快需降低-XX:MaxTenuringThreshold（对象晋升年龄阈值）‌。
‌控制Full GC风险‌：
- 确保IHOP阈值合理，避免老年代占用过快导致并发标记失败‌。
- 启用-XX:+G1HeapWastePercent（默认5%）加速混合回收，减少内存碎片‌。
‌混合回收调优‌：
- 通过-XX:G1MixedGCLiveThresholdPercent（默认85%）控制回收Region的存活对象比例，避免回收低效‌。
- 调整-XX:G1HeapWastePercent（默认5%）触发混合回收的堆浪费阈值‌。

四、典型配置示例‌

# 8核16G服务器，低延迟Web服务  
java -Xms16g -Xmx16g \  
     -XX:+UseG1GC \  
     -XX:MaxGCPauseMillis=150 \  
     -XX:InitiatingHeapOccupancyPercent=40 \  
     -XX:ConcGCThreads=2 \  
     -XX:G1HeapRegionSize=8m \

‌结论‌

G1回收器适用于‌大内存+多核CPU‌场景，核心优势在于可控的停顿时间和高吞吐量的平衡‌12。关键配置需围绕 ‌Region划分‌、‌并发线程数‌ 和 ‌停顿目标‌ 展开，避免因参数不当导致混合回收失败或Full GC频繁触发‌36。低内存（<4GB）或单核环境建议改用Serial或Parallel回收器‌

Parallel 回收器适用的最佳配置指南

‌一、核心参数配置‌

‌启用Parallel回收器‌
- -XX:+UseParallelGC：启用新生代并行回收（默认搭配Serial Old老年代回收器）‌。
- -XX:+UseParallelOldGC：同时启用新生代和老年代的并行回收（JDK 8默认配置）‌。
‌线程数优化‌
- -XX:ParallelGCThreads=<N>：设置并行回收线程数，‌默认值为CPU核心数‌。建议在CPU密集型应用中降低线程数以减少争抢（如2核环境设为1~2）‌。
‌堆内存分配‌
- -Xms与-Xmx：初始堆和最大堆设为相同值，‌避免动态扩展引发性能抖动‌（如4核8G服务器可设-Xms4g -Xmx4g）‌。
- ‌年轻代比例‌：通过-XX:NewRatio调整，默认年轻代占堆的40%（-XX:NewRatio=3表示年轻代占1/4）。‌高分配率应用建议增大年轻代至1/3~1/2‌，减少晋升频率‌。
‌吞吐量与停顿平衡‌
- -XX:MaxGCPauseMillis=<N>：设定最大GC停顿目标（默认200ms）。‌过低的设置（<50ms）可能导致频繁GC和吞吐量下降‌‌。
- -XX:GCTimeRatio=<N>：调整GC时间与应用时间比例（默认99，即GC占1%）。‌高吞吐场景可设为9（GC占10%）‌‌。

二、适用场景与硬件要求

‌

‌场景类型‌	‌推荐配置‌	‌硬件要求‌
‌多核计算密集型‌	高线程数（`-XX:ParallelGCThreads=CPU核心数`）+ 大年轻代（`-XX:NewRatio=1`）	CPU≥4核，内存≥8GB‌。
‌后台批处理任务‌	默认参数 + `-XX:GCTimeRatio=9`（允许更高GC占比）	CPU≥2核，内存≥4GB‌。
‌内存敏感型应用‌	限制堆大小（`-Xmx`）+ 小年轻代（`-XX:NewRatio=4`）	内存≤4GB，避免Full GC频繁触发‌。

三、优化建议与避坑指南‌

‌避免动态堆调整‌：固定-Xms和-Xmx值，减少堆扩容引发的性能波动‌。
‌监控晋升速率‌：若老年代增长过快，需增大年轻代或调整-XX:MaxTenuringThreshold（对象晋升年龄阈值）‌。
‌慎用低停顿目标‌：-XX:MaxGCPauseMillis低于100ms时，可能触发堆空间过度压缩，导致吞吐量下降20%~30%‌。
‌混合部署场景‌：若服务器同时运行多实例，需限制-XX:ParallelGCThreads，防止跨实例CPU争抢（如4核运行2实例，单实例线程数设为2）‌。

四、典型配置示例‌

# 4核8G服务器，高吞吐批处理场景  
java -Xms8g -Xmx8g \  
     -XX:+UseParallelGC \  
     -XX:+UseParallelOldGC \  
     -XX:ParallelGCThreads=4 \  
     -XX:NewRatio=1 \  
     -XX:GCTimeRatio=9

‌结论‌

Parallel回收器适用于‌多核CPU+大内存‌场景，核心优势在于最大化吞吐量（如科学计算、离线批处理）‌13。关键配置需平衡线程数、堆分区比例及停顿目标，避免过度优化导致资源争抢或内存碎片化‌26。低内存（<4G）或低延迟（<50ms）场景建议改用CMS或G1‌

‌Serial 回收器适用的最佳配置指南‌

‌一、适用场景与硬件要求‌

‌单核或低核心数环境‌：
Serial 回收器基于单线程工作模式，无多线程调度开销，在单核或双核 CPU 环境下能发挥最高效率，尤其适合嵌入式设备或低端服务器‌。
‌小内存应用‌：
推荐堆内存 ≤ 2GB，避免因堆过大导致单线程回收耗时长（如客户端应用、简单批处理任务）‌。
‌对延迟不敏感的场景‌：
因 GC 停顿（Stop-The-World）期间应用完全暂停，仅适用于容忍数百毫秒级停顿的非交互式应用（如离线计算、测试环境）‌。

二、核心参数配置‌

‌强制启用 Serial 回收器‌：

-XX:+UseSerialGC # 新生代 Serial + 老年代 Serial Old‌:ml-citation{ref="1,5" data="citationList"}
‌堆内存分配‌：
- ‌固定堆大小‌：设置 -Xms 和 -Xmx 相同值（如 -Xms512m -Xmx512m），避免动态扩展引发性能抖动‌。
- ‌年轻代比例‌：通过 -XX:NewRatio 调整（默认 NewRatio=3，年轻代占堆的 1/4），低内存场景可适当减小年轻代比例以降低晋升频率‌。
‌晋升阈值优化‌：
- -XX:MaxTenuringThreshold=15：调整对象晋升老年代的年龄阈值（默认 15），降低年轻代对象过早晋升的风险‌。

三、典型配置示例‌

# 单核 1GB 内存的嵌入式设备  
java -Xms512m -Xmx512m \  
     -XX:+UseSerialGC \  
     -XX:NewRatio=2 \  
     -XX:MaxTenuringThreshold=10

四、优化建议与限制‌

‌避免高内存场景‌：
堆内存超过 2GB 时，单线程回收效率显著下降，建议改用 Parallel 或 G1 回收器‌。
‌启用自适应策略‌：
-XX:+UseAdaptiveSizePolicy 允许 JVM 动态调整年轻代与老年代比例，减少手动调优成本‌。
‌限制后台线程干扰‌：
关闭非必要后台服务（如 JMX 监控），减少线程竞争对单线程 GC 的影响‌。

‌结论‌

Serial 回收器的核心优势在于 ‌极低的内存和 CPU 开销‌，适用于单核 CPU、小内存（≤2GB）且对停顿不敏感的场景‌。关键配置需固定堆大小、优化年轻代比例及晋升阈值，避免因参数不当引发频繁 Full GC。高并发或多核环境需优先选择并行或并发回收器（如 ParNew、G1）‌

是否建议使用 CMS 回收器？‌

‌一、CMS 回收器的适用性分析‌

‌适用场景‌
- ‌低延迟需求‌：CMS 以‌减少停顿时间‌为核心目标，适合需要快速响应的 Web 应用（如 Tomcat 服务）‌。
- ‌中等堆内存（4-8GB）‌：CMS 对内存碎片较敏感，堆内存过大会增加 Full GC 风险，建议堆内存≤8GB ‌。
- ‌多核 CPU 环境‌：CMS 默认占用 (CPU核心数+3)/4 的线程资源，推荐 CPU≥4 核，否则线程争抢可能影响应用性能 ‌。
‌潜在风险‌
- ‌内存碎片问题‌：CMS 采用标记-清除算法，长期运行后易产生内存碎片，可能导致 Full GC 触发（需切换至 Serial Old 回收器，引发长时间停顿）‌。
- ‌浮动垃圾累积‌：并发清理阶段可能残留未回收的“浮动垃圾”，需预留足够内存（通过 -XX:CMSInitiatingOccupancyFraction 调整触发阈值）‌。

二、Tomcat 使用 CMS 的配置建议‌

‌启用 CMS 回收器‌

# Tomcat 启动脚本（catalina.sh/catalina.bat）中设置 JAVA_OPTS="-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled"
‌关键参数调优‌
- ‌堆内存分配‌：固定 -Xms 和 -Xmx，避免动态扩展（如 -Xms4g -Xmx4g）‌。
- ‌触发阈值调整‌：
  
  -XX:CMSInitiatingOccupancyFraction=70 # 老年代占用70%时触发CMS回收（默认92%）
- ‌内存碎片缓解‌：
  
  -XX:+UseCMSCompactAtFullCollection # Full GC 时压缩内存 -XX:CMSFullGCsBeforeCompaction=0 # 每次 Full GC 后压缩

三、替代方案与对比‌

‌场景‌	‌推荐回收器‌	‌优势‌	‌限制‌
‌低延迟+中小堆（4-8GB）‌	CMS	停顿可控，适合交互式应用	CPU敏感，内存碎片风险高 ‌
‌大堆（>8GB）或高吞吐‌	G1	内存碎片少，支持可预测停顿时间	内存占用略高，低内存场景效率低 ‌
‌单核/小内存（≤2GB）‌	Serial	资源占用极低	仅适用非交互式任务，停顿时间长 ‌

‌结论‌

Tomcat ‌可短期使用 CMS 回收器‌，但需满足以下条件：

‌硬件要求‌：CPU≥4 核，堆内存≤8GB ‌12。
‌监控与调优‌：需实时监控 GC 日志，调整 CMSInitiatingOccupancyFraction 等参数，避免 Full GC 触发 ‌。

‌长期或高负载场景‌建议迁移至 ‌G1 回收器‌（JDK 9+默认），尤其在堆内存>8GB 或需稳定延迟控制的场景下，G1 的综合表现更优。

Tomcat 9 可用的垃圾回收器列表‌

Tomcat 9 支持的垃圾回收器取决于其运行的 ‌JDK 版本‌，以下是基于 JDK 8 及以上版本的常见可用回收器分类：

‌一、按分代类型分类‌

‌新生代回收器‌
- ‌Serial 收集器‌
  - 单线程工作，适用单核或小内存场景（如嵌入式系统）‌。
  - 启用参数：-XX:+UseSerialGC。
- ‌ParNew 收集器‌
  - Serial 的多线程版本，需搭配 CMS 使用，适合多核环境‌。
  - 启用参数：-XX:+UseParNewGC。
- ‌Parallel Scavenge 收集器‌
  - 以吞吐量优先，适合后台计算类应用‌。
  - 启用参数：-XX:+UseParallelGC。
‌老年代回收器‌
- ‌Serial Old 收集器‌
  - Serial 的老年代版本，单线程回收‌。
  - 启用参数：-XX:+UseSerialGC（需与 Serial 搭配）。
- ‌CMS（Concurrent Mark Sweep）收集器‌
  - 并发标记清除，减少停顿时间，但存在内存碎片风险（JDK 9 中已标记为废弃）‌。
  - 启用参数：-XX:+UseConcMarkSweepGC。
- ‌Parallel Old 收集器‌
  - Parallel Scavenge 的老年代版本，注重吞吐量‌。
  - 启用参数：-XX:+UseParallelOldGC。
‌全堆回收器‌
- ‌G1（Garbage-First）收集器‌
  - 分区化设计，支持可预测停顿时间，JDK 9+ 默认回收器‌。
  - 启用参数：-XX:+UseG1GC。
- ‌ZGC 与 Shenandoah（需高版本 JDK 支持）‌
  - ‌ZGC‌：JDK 11+ 支持，亚毫秒级停顿，适合超大堆‌。
  - ‌Shenandoah‌：JDK 12+ 支持，低延迟并发回收‌。

二、不同 JDK 版本的推荐组合‌

‌JDK 版本‌	‌可用回收器组合‌	‌适用场景‌
‌JDK 8‌	Serial/ParNew + CMS	低延迟 Web 服务（堆内存≤8GB）‌
‌JDK 8‌	Parallel Scavenge + Parallel Old	高吞吐批处理任务（如报表生成）‌
‌JDK 9+‌	G1（默认）或 ZGC/Shenandoah	大内存（≥16GB）或低延迟需求场景‌

三、配置示例‌

‌CMS 回收器（JDK 8）‌

JAVA_OPTS="-Xms4g -Xmx4g -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled"
‌G1 回收器（JDK 9+）‌

JAVA_OPTS="-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

结论‌

Tomcat 9 支持的垃圾回收器包括 ‌Serial、ParNew、Parallel Scavenge、CMS、G1‌ 等，具体选择需结合 ‌JDK 版本‌ 和 ‌业务需求‌：

‌低延迟场景‌：优先选择 CMS（JDK 8）或 G1/ZGC（JDK 9+）‌。
‌高吞吐场景‌：使用 Parallel Scavenge + Parallel Old‌8。
‌大内存场景‌（≥16GB）：推荐 G1 或 ZGC‌

‌按服务器内存配置划分的回收器最佳配置指南‌

‌一、小内存配置（1-4GB）‌

‌推荐回收器‌：‌Serial 或 ParNew + CMS‌
- ‌适用场景‌：单核/双核 CPU、低负载 Web 应用或嵌入式系统，容忍数百毫秒级 GC 停顿‌。
- ‌配置参数‌：
  
  # Serial 回收器（JDK 8 及以下） -Xms1g -Xmx1g -XX:+UseSerialGC # ParNew + CMS（需 JDK 8 及以下） -Xms2g -Xmx2g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
- ‌优化建议‌：
  - 固定堆大小（-Xms=-Xmx），避免动态扩展‌；
  - 调整 -XX:MaxTenuringThreshold 降低晋升频率‌。

二、中等内存配置（4-8GB）‌

‌推荐回收器‌：‌CMS 或 G1‌
- ‌适用场景‌：多核 CPU、需低延迟的 Web 服务（如 Tomcat），堆内存≤8GB‌。
- ‌配置参数‌：
  
  # CMS 回收器（JDK 8 及以下） -Xms4g -Xmx4g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 # G1 回收器（JDK 9+） -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200
- ‌优化建议‌：
  - CMS 需预留 20%-30% 堆空间避免并发失败‌；
  - G1 设置 -XX:MaxGCPauseMillis 控制目标停顿时间‌。

三、大内存配置（8-16GB+）‌

‌推荐回收器‌：‌G1 或 ZGC/Shenandoah‌
- ‌适用场景‌：高并发、大堆内存（≥8GB）、需亚毫秒级停顿的云原生应用（JDK 11+）‌。
- ‌配置参数‌：
  
  # G1 回收器（JDK 9+） -Xms16g -Xmx16g -XX:+UseG1GC -XX:G1HeapRegionSize=4M # ZGC 回收器（JDK 11+） -Xms32g -Xmx32g -XX:+UseZGC -XX:ZAllocationSpikeTolerance=5
- ‌优化建议‌：
  - G1 设置 -XX:G1HeapRegionSize 适配对象大小分布‌；
  - ZGC 需预留 15%-20% 内存支持并发标记‌。

四、关键参数通用优化‌

‌堆内存管理‌：
- ‌固定堆大小‌：-Xms 与 -Xmx 设为相同值（如 -Xms8g -Xmx8g），避免 GC 后堆扩容/缩容‌。
- ‌年轻代比例‌：
  - CMS 场景通过 -XX:NewRatio 调整（默认 2，即年轻代占 1/3）‌；
  - G1 场景由 JVM 自动管理，无需手动设置‌。
‌元空间与线程配置‌：
- ‌元空间限制‌：JDK 8+ 使用 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 替代 PermGen‌；
- ‌线程池优化‌：Tomcat 的 maxThreads 需与 CPU 核心数匹配，避免线程争抢‌。

‌结论‌

‌小内存（1-4GB）‌：优先选择 Serial 或 CMS，注重资源占用和简单性‌；
‌中等内存（4-8GB）‌：根据 JDK 版本选择 CMS（JDK 8）或 G1（JDK 9+），平衡延迟与吞吐‌；
‌大内存（8GB+）‌：必选 G1 或 ZGC/Shenandoah，支持超大堆和低延迟‌。
‌通用规则‌：固定堆大小、监控 Full GC 频率、根据业务负载动态调整参数‌.

Serial 与 CMS 垃圾回收器的核心区别‌

‌一、线程模型与工作方式‌

‌Serial 回收器‌
- ‌单线程执行‌：仅使用‌单个线程‌完成垃圾回收任务，全程需 ‌Stop-the-World（STW）‌，暂停所有应用线程‌。
- ‌分代处理‌：
  - ‌新生代‌：采用‌复制算法‌（标记-复制），清理效率高但需预留 50% 内存空间‌。
  - ‌老年代‌：Serial Old 使用‌标记-整理算法‌，单线程回收，适合与 Parallel Scavenge 搭配‌5。
‌CMS 回收器‌
- ‌并发多线程‌：通过‌并发标记‌与‌并发清除‌减少 STW 时间（仅初始标记与重新标记阶段需短暂停顿）‌。
- ‌算法设计‌：
  - ‌标记-清除算法‌：不压缩内存，易产生‌内存碎片‌，可能导致 Full GC 触发时性能下降‌。
  - ‌增量回收‌：允许部分垃圾回收与应用程序交替执行，降低单次停顿时长‌。

二、性能与适用场景‌

‌维度‌	‌Serial‌	‌CMS‌
‌停顿时间‌	长（全程 STW）‌	短（仅初始标记和重新标记阶段 STW）‌
‌吞吐量‌	低（单线程占用 CPU）‌	中高（并发执行减少资源争抢）‌
‌内存占用‌	低（复制算法需 50% 预留空间）‌	高（需预留内存避免并发失败）‌
‌适用场景‌	单核 CPU、客户端模式、测试环境‌	多核 CPU、低延迟 Web 服务（堆≤8GB）‌

三、内存管理与碎片问题‌

‌Serial‌：
- 老年代通过‌标记-整理‌消除碎片，内存分配采用‌指针碰撞‌（无碎片）‌。
‌CMS‌：
- 标记-清除算法导致‌内存碎片累积‌，需依赖 ‌Full GC‌ 或 -XX:+UseCMSCompactAtFullCollection 压缩内存‌。
- ‌浮动垃圾‌：并发清理阶段可能残留未回收对象，需预留空间（通过 -XX:CMSInitiatingOccupancyFraction 控制触发阈值）‌。

四、兼容性与版本演进‌

‌Serial‌：
- JDK 1.3.1 前为新生代唯一选择，JDK 8+ 仍支持，但仅推荐用于‌客户端模式‌或低资源环境‌。
‌CMS‌：
- JDK 9+ 中标记为‌废弃‌（Deprecated），JDK 14+ 正式移除，建议迁移至 ‌G1 或 ZGC‌‌。

‌结论‌

‌Serial‌：单线程、高内存效率、适合低资源场景，但‌停顿时间长‌，不适用于高并发服务‌。
‌CMS‌：多线程并发、低延迟，但‌内存碎片风险高‌，且已逐步被淘汰.

ZGC 与 G1 垃圾回收器的核心区别‌

‌一、设计目标与适用场景‌

‌ZGC‌
- ‌目标‌：实现‌亚毫秒级停顿‌（≤10ms），且停顿时间不随堆容量或活跃对象数量增加而延长，支持 ‌TB 级堆内存‌‌。
- ‌适用场景‌：超大内存（≥16GB）、低延迟敏感型应用（如实时交易系统、云原生服务），需 JDK 11+‌。
‌G1‌
- ‌目标‌：平衡‌高吞吐量‌和‌可控停顿时间‌（通常 200ms 内），默认采用‌分代+区域化‌内存管理‌34。
- ‌适用场景‌：中等至大内存（4GB-16GB）、需可预测停顿的通用服务（如 Web 应用），JDK 9+ 默认回收器‌。

二、内存管理与回收策略‌

‌维度‌	‌ZGC‌	‌G1‌
‌内存划分‌	‌无分代‌，全堆划分为动态大小 Region（2MB/32MB）‌	‌分代+分区‌，固定大小 Region（1MB-32MB）‌
‌回收算法‌	并发标记-整理（染色指针+读屏障）‌	并发标记-整理（SATB 写屏障+增量整理）‌
‌碎片处理‌	通过‌并发整理‌消除碎片，无需 Full GC‌	‌增量整理‌，依赖混合 GC 阶段减少碎片‌

三、并发能力与停顿控制‌

‌ZGC‌
- ‌全阶段并发‌：包括标记、转移、重定位等均与应用线程并发执行，仅初始标记需极短 STW（通常 <1ms）‌。
- ‌染色指针‌：通过指针元数据（Metadata Bits）记录对象状态，减少内存访问屏障开销‌。
‌G1‌
- ‌部分并发‌：仅‌并发标记‌阶段与应用线程交替运行，‌转移阶段‌（Evacuation）需 STW‌。
- ‌SATB 写屏障‌：记录对象引用变化，确保标记准确性，但可能增加内存写入开销‌。

四、性能与资源消耗‌

‌维度‌	‌ZGC‌	‌G1‌
‌吞吐量‌	中等（侧重低延迟，牺牲部分吞吐）‌	高（优化吞吐与延迟平衡）‌
‌内存开销‌	高（需预留 15%-20% 堆内存支持并发操作）‌	中（RSet 和 Card Table 占用额外空间）‌
‌CPU 占用‌	高（依赖多线程并发处理）‌	中（可控的并行线程数）‌

五、版本支持与生产建议‌

‌ZGC‌：需 JDK 11+，JDK 15+ 支持生产环境，适合‌超大堆+低延迟‌需求，但需更高硬件资源‌。
‌G1‌：JDK 7+ 可用，JDK 9+ 默认，适合‌通用服务‌，平衡资源消耗与性能，社区成熟度高‌。

‌结论‌

‌延迟敏感型场景‌（如金融交易）：优先选择 ‌ZGC‌，确保亚毫秒级停顿和堆扩展性‌。
‌通用服务场景‌（如 Web 应用）：‌G1‌ 更优，兼顾吞吐量和可控停顿，资源消耗更低‌。
‌迁移建议‌：从 G1 切换到 ZGC 需评估硬件资源（CPU/内存）和 JDK 版本兼容性‌

配置建议
配置	建议	理由
内存小于2G ， CPU核心小于4	Serial 回收器	回收器对资源要求低,速度快
内存2 ~ 8G 2核以上	Parallel	适合多核要求,并能为回收器提供适宜的运行资源
内存 8 ~ 16G 多核	G1	适合多核要求,并能为回收器提供适宜的运行资源
内存大于 16G 多核	ZGC	适合多核要求,并能为回收器提供适宜的运行资源

上一篇:xlang 5.0内置类大全下一篇:xlang webserver 用法详解

xlang - blog

tomcat 服务器问题排查及优化

问题: tomcat 服务器内存占用过高，而查看快照时却发现使用的内存并不多，假设已排除 native 组件占用内存的问题。

案例1:

服务器内存过小场景下 G1 回收器的局限性分析‌

‌1. 内存开销与 Region 机制冲突‌

‌2. 预测模型与停顿控制失效‌

‌3. 对比其他回收器的适用性‌

结论

案例2:

在2G内存2核服务器上使用Parallel GC的局限性分析‌

‌1. 资源竞争严重，CPU利用率过高‌

‌2. 内存不足引发频繁Full GC‌

‌3. 对比其他回收器的适用性‌

‌

结论

G1 回收器适用的最佳配置指南

‌一、核心参数配置‌

二、适用场景与硬件要求

‌

三、优化建议与避坑指南‌

四、典型配置示例‌

‌结论‌

Parallel 回收器适用的最佳配置指南

‌一、核心参数配置‌

二、适用场景与硬件要求

‌

三、优化建议与避坑指南‌

四、典型配置示例‌

‌结论‌

‌Serial 回收器适用的最佳配置指南‌

‌一、适用场景与硬件要求‌

二、核心参数配置‌

三、典型配置示例‌

四、优化建议与限制‌

‌结论‌

是否建议使用 CMS 回收器？‌

‌一、CMS 回收器的适用性分析‌

二、Tomcat 使用 CMS 的配置建议‌

三、替代方案与对比‌

‌结论‌

Tomcat 9 可用的垃圾回收器列表‌

‌一、按分代类型分类‌

‌新生代回收器‌

‌老年代回收器‌

‌全堆回收器‌

二、不同 JDK 版本的推荐组合‌

三、配置示例‌

结论‌

‌按服务器内存配置划分的回收器最佳配置指南‌

‌一、小内存配置（1-4GB）‌

二、中等内存配置（4-8GB）‌

三、大内存配置（8-16GB+）‌

四、关键参数通用优化‌

‌结论‌

Serial 与 CMS 垃圾回收器的核心区别‌

‌一、线程模型与工作方式‌

二、性能与适用场景‌

三、内存管理与碎片问题‌

四、兼容性与版本演进‌

‌结论‌

ZGC 与 G1 垃圾回收器的核心区别‌

‌一、设计目标与适用场景‌

二、内存管理与回收策略‌

三、并发能力与停顿控制‌

四、性能与资源消耗‌

五、版本支持与生产建议‌

‌结论‌

评论

写评论