java垃圾回收器不支持手动触发内存整理，是否压缩取决于收集器类型：serial和parallel gc在full gc时自动压缩老年代以消除碎片；zgc、shenandoah通过并发重定位/疏散实现低延迟无碎片；而cms（已废弃）和g1默认不压缩，易产生碎片，仅在退化full gc时用serial old单线程压缩。
Java 垃圾回收器本身不提供“手动触发内存整理”这一操作，因为是否整理（即压缩）取决于所使用的垃圾收集器类型及其运行策略。内存碎片主要出现在老年代（Old Generation），尤其是使用 CMS（已废弃）或 G1（默认不压缩老年代）时可能产生；而真正能主动压缩堆内存、消除碎片的收集器是 Serial、Parallel（吞吐量优先）、ZGC 和 Shenandoah（部分压缩）等。
哪些 GC 会自动整理内存（压缩）
以下收集器在执行 Full GC 或特定阶段时，会对老年代进行压缩，从而消除碎片：
- Serial GC：单线程，每次 Full GC 都会压缩老年代（标记-压缩算法）。
-
Parallel GC（吞吐量收集器）：默认开启老年代压缩（
-XX:+UseParallelOldGC，JDK8+ 默认启用），Full GC 时执行压缩。 - ZGC：并发标记 + 并发重定位，通过重定位实现无碎片，无需 Stop-The-World 压缩。
- Shenandoah：通过并发疏散（Evacuation）移动对象，天然减少碎片。
CMS 和 G1 不压缩，所以容易出碎片
CMS（Concurrent Mark-Sweep）已从 JDK14 起移除，它只清理不移动对象，长期运行后老年代易产生大量小块碎片，导致“concurrent mode failure”或 promotion failure；G1 虽有区域化设计，但默认仅对回收价值高的 Region 进行回收（不移动），Full GC 时才压缩——而 G1 的 Full GC 是单线程 Serial GC，代价高且应尽量避免。
若发现频繁 Full GC 或 java.lang.OutOfMemoryError: GC overhead limit exceeded 伴随可用空间充足但无法分配大对象，大概率是碎片问题。
如何促使压缩发生（非强制，但可引导）
没有“立即整理内存”的 API，但可通过配置让 GC 更倾向压缩或更快进入压缩流程：
- 显式启用 Parallel Old GC：
-XX:+UseParallelGC -XX:+UseParallelOldGC（JDK9+ 默认开启，无需额外加）。 - 降低触发 Full GC 的阈值（谨慎）：
-XX:MaxHeapFreeRatio=30（堆空闲超30%就尝试缩小，可能连带触发压缩）。 - 避免大对象直接进入老年代：
-XX:PretenureSizeThreshold设低些，或调小-XX:MaxTenuringThreshold，让对象尽早晋升并集中回收。 - 监控碎片情况：用
jstat -gc <pid></pid>观察OU（老年代已用）和OC（老年代容量）比值接近 100%，同时FGCT（Full GC 次数）上升，说明碎片风险高。
替代方案：换 GC 或调优避免碎片
与其等待或“触发整理”，不如预防碎片：
- 升级到 JDK17+，用 ZGC（
-XX:+UseZGC）或 Shenandoah（-XX:+UseShenandoahGC），它们在低延迟下保持低碎片。 - 若必须用 G1，可开启
-XX:+G1EagerReclaimHumongousObjects及时回收巨型对象，减少大块碎片。 - 合理设置堆大小与新生代比例：
-Xms=Xmx避免动态扩容带来的不连续；-XX:NewRatio=2等控制新/老比例，减少老年代过早填满。 - 排查是否存在内存泄漏或缓存未释放（如 static Map 持有对象），这才是碎片频发的根本原因之一。
不复杂但容易忽略：碎片不是孤立问题，它往往是对象生命周期异常、分配模式失衡或 GC 策略不匹配的结果。先看日志、再选 GC、最后调参，比强行“触发整理”更有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
