今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。因为文章很长，每一个人阅读习惯不一样，因此特此拆成单篇版和多篇版算法

1. 观前提醒

本期内容比较硬核，很是全面，涉及到了设计思想到实现原理以及源码，而且还给出了相应的日志以及监控方式，若是有不清楚或者有疑问的地方，欢迎留言。多线程

其中涉及到的设计思想主要为我的理解，实现原理以及源码解析也是我的整理，若是有不许确的地方，很是欢迎指正！提早感谢~~.net

2. 分配内存实现思路

咱们常常会 new 一个对象，这个对象是须要占用空间的，第一次 new 一个对象占用的空间如 图00 所示，线程

咱们这里先只关心堆内部的存储，元空间中的存储，咱们会在另外一个系列详细讨论。堆内部的存储包括对象头，对象体以及内存对齐填充，那么这块空间是如何分配的呢？设计

首先，对象所需的内存，在对象的类被解析加载进入元空间以后，就能够在分配内存建立前计算出来。假设如今咱们本身来设计堆内存分配，一种最简单的实现方式就是线性分配，也被称为撞针分配（bump-the-pointer）。指针

每次须要分配内存时，先计算出须要的内存大小，而后 CAS 更新如 图01 中所示的内存分配指针，标记分配的内存。可是内存通常不是这么整齐的，可能有些内存在分配有些内存就被释放回收了。因此通常不会只靠撞针分配。一种思路是在撞针分配的基础上，加上一个 FreeList。日志

简单的实现是将释放的对象内存加入 FreeList，下次分配对象的时候，优先从 FreeList 中寻找合适的内存大小进行分配，以后再在主内存中撞针分配。对象

这样虽然必定程度上解决了问题，可是目前大多数应用是多线程的，因此内存分配是多线程的，都从主内存中分配，CAS 更新重试过于频繁致使效率低下。目前的应用，通常根据不一样业务区分了不一样的线程池，在这种状况下，通常每一个线程分配内存的特性是比较稳定的。这里的比较稳定指的是，每次分配对象的大小，每轮 GC 分配区间内的分配对象的个数以及总大小。因此，咱们能够考虑每一个线程分配内存后，就将这块内存保留起来，用于下次分配，这样就不用每次从主内存中分配了。若是能估算每轮 GC 内每一个线程使用的内存大小，则能够提早分配好内存给线程，这样就更能提升分配效率。这种内存分配的实现方式，在 JVM 中就是 TLAB （Thread Local Allocate Buffer）。blog

3. JVM 对象堆内存分配流程简述

咱们这里不考虑栈上分配，这些会在 JIT 的章节详细分析，咱们这里考虑的是没法栈上分配须要共享的对象。接口

对于 HotSpot JVM 实现，全部的 GC 算法的实现都是一种对于堆内存的管理，也就是都实现了一种堆的抽象，它们都实现了接口 CollectedHeap。当分配一个对象堆内存空间时，在 CollectedHeap 上首先都会检查是否启用了 TLAB，若是启用了，则会尝试 TLAB 分配；若是当前线程的 TLAB 大小足够，那么从线程当前的 TLAB 中分配；若是不够，可是当前 TLAB 剩余空间小于最大浪费空间限制（这是一个动态的值，咱们后面会详细分析），则从堆上（通常是 Eden 区）从新申请一个新的 TLAB 进行分配。不然，直接在 TLAB 外进行分配。TLAB 外的分配策略，不一样的 GC 算法不一样。例如G1：

若是是 Humongous 对象（对象在超过 Region 一半大小的时候），直接在 Humongous 区域分配（老年代的连续区域）。
根据 Mutator 情况在当前分配下标的 Region 内分配

全网最硬核 JVM TLAB 分析 1. 内存分配思想引入

1. 观前提醒

2. 分配内存实现思路

3. JVM 对象堆内存分配流程简述