线程堆空间的分配本质：为什么它注定会产生碎片
当我们在代码里写下new Thread().start()时，操作系统并不会直接到堆上划一块内存给线程——这项工作由语言运行时配合操作系统共同完成。以HotSpot JVM为例，每个Java线程除了拥有私有的程序计数器和本地方法栈外，最耗内存的就是线程栈（Thread Stack）和ThreadLocal关联的数据结构。默认情况下，64位系统上的线程栈大小为1MB，这部分空间虽然被称为“栈”，但在JVM内部的实际实现中，它是在堆外内存或通过mmap分配的一块区域。然而，很多开发者忽略的是，线程对象本身、ThreadLocalMap以及与之关联的值，都是放在堆里的。如果你在短时间内创建了大量线程，并且在业务执行完毕后让这些线程消亡，那么堆上就会反复经历“分配线程对象-填充ThreadLocal-回收线程对象”的循环。
问题的核心在于，这些对象的尺寸并不统一。不同的线程可能在运行时往ThreadLocal里塞入大小差异巨大的值，比如有的线程只存一个32字节的用户ID，而另一个线程可能缓存了一个4KB的数据库连接上下文。当这些线程几乎同时死亡时，垃圾回收器会在堆中标记出大量不同大小的空洞。标记-清除或复制算法虽然能回收这些内存，但物理上只能留下离散的空闲块，无法自动将它们拼接成一块连续的大内存。这就是外部碎片化的典型表现。如果下一个新线程的ThreadLocal需要一块16KB的连续空间，而堆中最长的空闲块只有12KB，那么即便总空闲内存高达几百MB，分配也会失败，进而可能触发频繁的Full GC甚至直接报OutOfMemoryError。
再深入一层，现代JVM中的TLAB（Thread Local Allocation Buffer）机制本意是减少线程间分配竞争，但面对极短生命周期的线程时反而会加剧碎片化。每个线程启动时，JVM会在Eden区为它划出一块私有的TLAB，用来快速分配小对象。如果线程存活时间很短，其TLAB可能只被填充了一小部分就随线程死亡而退役，这部分未用完的TLAB空间会被标记为可回收，但物理上仍是一片片零碎的“小蛋糕渣”，后续分配中大型对象时完全无法利用。这种碎片化积累到一定程度后，会让原本流畅的并发程序变得卡顿不堪。
频繁创建短生命周期线程的实际破坏力：从GC日志到系统抖动
为了直观感受这种破坏力，我们可以模拟一个场景：一个Web服务使用每个请求一个线程的模型，请求处理极快（平均1ms），但瞬时并发很高，导致每秒会新建和销毁上千个线程。从表面看，堆内存设置得足够大（比如4GB），新生代也有2GB，按理内存绰绰有余。但运行几分钟后，GC频率急剧攀升，甚至开始出现Concurrent Mode Failure，最终JVM陷入长时间的Stop The World。查看GC日志，会发现大量“To Space Overflow”或“Promotion Failed”，但是老年代使用率其实只有40%左右。这其实并不是真正的内存不足，而是老年代中存在大量碎片，导致新生代存活对象晋升时找不到连续的块存放。
具体到堆空间的分布，短命线程制造的碎片主要分布在两个区域：一是Eden区中由TLAB退役和短命对象释放形成的小空洞，二是老年代中由长期存活的线程元数据（如继承性InheritableThreadLocal的值）被清除后留下的孔洞。当并发量持续维持在高位时，Eden区的碎片使得新生代回收效率大打折扣，原本一次Minor GC可能只需要十几毫秒，现在由于大量碎片导致复制算法需要反复跳跃寻找存活对象，耗时可能膨胀到上百毫秒。更糟糕的是，如果应用本身逻辑中存在一些本该进入老年代的“老年”对象（比如缓存的配置），它们会因为老年代的碎片化而被反复回收、晋升失败，最终触发Full GC，整个系统响应时间毛刺频出。
这种情况在C++这类手动管理内存的环境中也会有类似表现，只不过形式更为隐蔽。如果你使用pthread_create频繁创建撤销线程，每个线程默认栈大小通常为8MB（Linux），这些栈空间由mmap分配，离开进程虚拟地址空间后，如果munmap不及时或者分配器内部缓存策略不当，就会在虚拟地址空间中留下很多孤立的未映射区域。当应用需要分配一块大的mmap区域（比如加载动态库或分配大块共享内存）时，尽管空闲物理内存还很充裕，虚拟地址空间的碎片化却可以导致mmap失败，返回ENOMEM。这种碎片化比堆内碎片更隐蔽，因为常规的top或free命令根本看不出来，需要借助/proc/pid/maps或pmap工具才能诊断。
诊断工具和实战规避方案：从测量到重构
要彻底解决线程带来的堆碎片化，第一步是量化和定位。对于JVM应用，可以给应用加上-XX:+PrintGCDetails -XX:+PrintHeapAtGC参数，然后在GC日志中寻找“[Eden: ...]”块中频繁出现的(promotion failed)字样。碎片化的另一直接证据是堆转储文件中大量的细小空闲区域。使用jmap -dump:live,format=b,file=heap.bin导出堆后，用Eclipse MAT或VisualVM打开，查看“Unreachable Objects Histogram”并按大小分组，如果存在大量几十字节到几百字节不等的空闲对象，且没有一块连续超过数MB的空闲区域，就基本可以断定碎片化严重。对于原生代码，可以利用malloc_info或jemalloc的统计功能输出各大小类别的分配情况，重点观察“runs”中碎片占比。
找到问题后，最直接的规避手段当然是削减短命线程的数量。如果业务模型是请求-线程一对一的，可以考虑迁移到线程池或协程模型。以Java为例，使用ExecutorService固定大小的线程池，可以避免线程反复创建带来的TLAB和线程栈分配抖动，因为线程复用后其ThreadLocal空间会保持稳定，不会反复释放和重分配。如果业务必须使用大量短暂线程（例如压测工具），可以调小线程栈大小（-Xss256k）来降低每个线程占用的连续空间，减少大块空洞出现的概率。同时，可以主动在业务低峰期调用System.gc()（谨慎使用）结合-XX:+UseG1GC这类自带整理功能的垃圾收集器，G1在Mixed GC阶段会主动去老年代碎片化整理，能显著缓解碎片压力。
更进一步的方案是对ThreadLocal使用进行严格规约。很多框架会在请求线程入口自动塞入TraceId、用户信息等，如果这些信息占用的内存较大且生命周期与线程不同步，就会成为碎片制造者。可以为这些上下文对象设计对象池或使用SoftReference包装，使得当线程死亡时内存能被更快回收并合并。另外，一些语言运行时提供了专门针对碎片的内存分配策略，例如Go语言使用tcmalloc（线程缓存分配），它将内存按大小分成多个span类，并尽量在同一个span内分配相同大小的对象，天然降低了碎片风险。如果你的应用是C++编写，可以考虑替换默认的ptmalloc2为jemalloc，它能通过精细化的尺寸分级和主动的缓存退役策略，将碎片率控制在5%以下。
总而言之，并发中的内存碎片化不是玄学，而是由频繁创建短生命周期线程引发的一系列可量化的内存管理问题。只要理解线程内存分配的底层机制，借助合适的监控工具，通过线程复用、栈大小调优、合理的ThreadLocal管理以及更智能的分配器，完全可以让堆空间恢复整洁，避免那种“内存有余、分配失败”的诡异故障。