老年代不适合用复制算法，因其高存活率导致复制开销巨大、空间需求翻倍、引用更新成本高且破坏内存局部性。

老年代不适合用复制算法，根本原因在于它的对象特征和复制算法的运行机制严重不匹配——不是算法本身不好，而是放错了地方。

存活率太高，复制变成“搬全家”

老年代里对象普遍活了很久，存活率常达70%～95%。复制算法要搬的是所有存活对象，意味着每次回收几乎要把整个老年代的数据重新拷贝一遍。这不像新生代只搬3%的幸存者，而是搬95%的“原住民”，耗时远超标记清除或整理。

• 复制耗时与存活对象数量成正比，不是与垃圾数量相关
• 一次老年代GC若需移动数GB存活数据，STW（Stop-The-World）时间可能达数百毫秒甚至秒级
• 实际中，复制操作本身可能比直接标记+清理更慢

空间开销不可承受

复制算法必须预留一块同等大小的空闲内存作目标区。而老年代通常占堆内存60%以上，再配一块同容量区域，等于堆内存翻倍才够用——既不现实，也违背资源高效利用原则。

宝塔Linux面板11.3.0

宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。

下载

• 例如堆总大小8GB，老年代占5GB，那就要额外预留5GB空闲空间
• HotSpot中没有为老年代设计这样的双区结构，Survivor区只存在于年轻代
• 所谓“分配担保”靠的是老年代本身承接大对象，而非为复制准备备用空间

引用更新成本巨大

对象地址一变，所有指向它的引用都得重写。这些引用不仅来自栈帧、寄存器，还可能跨代（如年轻代对象引用老年代）、来自元空间（如类静态字段），甚至被JIT编译器内联固化。

• 更新过程必须全程STW，无法并发完成
• 引用数量随存活对象线性增长，且涉及多线程上下文扫描，开销陡增
• 现代大堆（数十GB）+高并发场景下，这部分延迟成为主要瓶颈

破坏内存局部性，拖慢整体性能

长期驻留对象原本在内存中分布相对稳定，CPU缓存对其访问有良好命中率。复制算法强制移动它们，打乱原有布局，导致后续访问缓存失效增多，吞吐下降。

• 尤其影响频繁读取的老年代热点对象（如缓存、配置、单例）
• 这种间接开销不易被GC日志捕获，但真实存在
• 标记-整理虽也移动对象，但只向一端压缩，局部性损失可控；复制是全量随机重分布