复制算法最直接的局限性是内存空间利用率被硬性限制在50%左右，因其必须划分两块大小相等的区域（From/To）交替使用，GC时需整块空闲区承接存活对象，无法动态复用未填满空间；现代JVM通过Eden+S0+S1（8:1:1）优化至约90%利用率，但本质仍是该机制的变种，牺牲空间换取零碎片与确定性回收。
复制算法最直接的局限性，就是内存空间利用率被硬性限制在50%左右——它必须预留一块同等大小的空闲区域用于对象迁移，本质上是用一半空间换连续性和低碎片。
为什么必须“浪费”一半内存？
复制算法依赖两块大小相等的内存区域（From/To）交替工作。GC触发时，存活对象被整体搬移到空闲区，原区域则整块清空。这个机制决定了：任何时候都必须有一块完整空闲区待命，无法动态压缩或复用已分配但未填满的空间。
- 哪怕From区只用了30%，只要触发GC，仍需To区100%可用才能完成复制
- 现代JVM新生代虽采用Eden+S0+S1结构（比例约8:1:1），但本质仍是复制逻辑的变种——S0/S1轮流作To区，总保留约20%空间专用于复制中转
- 这种设计不是疏忽，而是权衡：牺牲空间换确定性的回收时间与零碎片保障
高内存占用在实际场景中如何放大？
当复制行为脱离JVM堆内、延伸到数据系统层面（如文件复制、跨集群同步），空间利用率问题会叠加IO和缓冲开销，形成更明显的瓶颈。
- AList等工具若用
os.ReadFile一次性加载大文件，等于把“复制算法”的空间浪费从堆内存转移到进程内存——1GB文件强制占用1GB RAM，无法分段释放 - 大数据管道中，若复制任务未做流式处理，中间结果缓存可能持续占满分配内存，导致频繁GC甚至OOM，而实际有效数据占比可能不足10%
- 内存池若按复制逻辑预分配双倍缓冲区，但业务请求不均衡（例如突发小文件+长周期大文件混合），闲置缓冲区会长期滞留
哪些优化能缓解但无法根除该瓶颈？
所有改进都在“接受50%理论上限”的前提下做腾挪，核心思路是让闲置空间更可控、更贴近实际负载。
- 动态缓冲区分级：按文件大小切换64KB/1MB/4MB缓冲，避免小文件也配大块空闲区
- 分块流式复制：读一段、写一段、释放一段，使内存驻留峰值远低于文件总大小
- 对象年龄分流：JVM中将长期存活对象提前晋升至老年代，减少其在新生代复制区的反复搬运
归根结底，复制算法的内存效率天花板是设计契约的一部分。它解决的是碎片和停顿问题，而不是空间问题。选它，就意味着接受“用空间换确定性”的交易——关键在于让这笔交易在具体场景里算得过来。
