64位JVM优化对象分配的核心抓手只有三件事：用压缩指针压住对象头膨胀、用TLAB把分配动作本地化、用逃逸分析把能拆的对象拆到栈上，三步做到位，对象分配基本就是指针加偏移的纳秒级操作。
32位和64位JVM内存模型区别在哪：引用膨胀与压缩指针
32位JVM受限的是地址空间,64位JVM放开的是寻址能力，但代价也很直接每个对象引用从4字节涨到8字节，对象头里的类型指针同样翻倍，堆里的对象越多，这笔账越明显。
对象头从8+4到8+8的差别
普通对象在HotSpot里的布局是Mark Word加Klass Pointer，32位下是4加4共8字节，64位不压缩时是8加8共16字节，一个只装了个int字段的小对象，字段本身4字节，对象头却占16字节，实际内存占用还要按8字节对齐向上取整。
| 模型 | Mark Word | Klass Pointer | 引用宽度 | 小对象典型体积 |
|---|---|---|---|---|
| 32位 | 4字节 | 4字节 | 4字节 | 8字节对象头 |
| 64位无压缩 | 8字节 | 8字节 | 8字节 | 16字节对象头 |
| 64位开压缩指针 | 8字节 | 4字节 | 4字节 | 12字节对象头 |
表里最后一行的12字节,是大量小对象能被“塞”进同一缓存行的关键，业内专家指出，缓存行利用率对分配吞吐的影响，往往比很多人想象的大。
压缩指针怎么把引用瘦身
-XX:+UseCompressedOops 在堆最大内存不超过32GB时默认开启（据Oracle官方文档），原理不复杂：对象地址按8字节对齐，低3位恒为0，存引用时右移3位当偏移量存，取值时再左移回来，4字节偏移乘8，正好覆盖32GB。
开启方式很简单,显式写一遍便于排查：
java -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -jar app.jar验证是否生效：
java -XX:+PrintFlagsFinal -version | grep CompressedOops输出里 UseCompressedOops := true 就说明生效了。
对齐填充与ObjectAlignmentInBytes
想突破32GB上限,可以调 -XX:ObjectAlignmentInBytes=16，把压缩指针的覆盖范围拉到64GB，代价是对象对齐从8字节变成16字节，小对象平均浪费更多空间，这是个典型的两头堵：要么堆超32GB丢掉压缩指针，要么加大对齐粒度换空间利用率，行业共识认为，堆规模在32GB附近的系统，先评估对象体积分布再决定，比拍脑袋调参靠谱。
64位JVM对象分配慢怎么办：从指针碰撞到TLAB
分配慢通常不是CPU慢,而是线程抢同一块内存，HotSpot在Eden区用指针碰撞分配，一个指针记录当前空闲位置，分配就是移动指针，问题在于这个指针是共享的。
分配路径拆解
- 新对象先尝试在当前线程的TLAB里分配,只动自己的指针，无需同步。
- TLAB空间不够,尝试在Eden区重新申请一块新的TLAB。
- 申请TLAB本身需要加锁,走CAS。
- 对象太大装不进TLAB,退回共享Eden区分配。
- 超过阈值的大对象,直接进老年代。
路径越靠后,开销越大，所以优化的方向是把请求尽可能留在第1步。
TLAB参数怎么调
-XX:+UseTLAB 在64位HotSpot上默认开启，一般不用动，需要动的是尺寸：
-XX:TLABSize=512k
-XX:MinTLABSize=16k
-XX:TLABWasteTargetPercent=1TLABWasteTargetPercent 控制TLAB允许的浪费比例，默认1%，业务里存在大量中等对象、频繁触发TLAB重申请的，把它调到2到5，能减少重申请次数。
想直接看浪费情况,打开 -XX:+PrintTLAB，日志里会打印每个线程的waste占比，浪费率高说明TLAB尺寸与对象大小不匹配。
大对象别硬塞进年轻代
-XX:PretenureSizeThreshold 可以设置超过该值的对象直接进老年代，注意它只对Serial和ParNew收集器有效，G1下不生效，G1里靠的是 -XX:G1HeapRegionSize 和Humongous对象判定，超过Region一半大小的对象被视为Humongous，单独占用连续Region，频繁产生大数组的应用，把Region调大能减少Humongous分配失败，常见做法是按业务对象大小分布，把RegionSize设成2MB到16MB。
逃逸分析和标量替换：不改代码也能省掉分配
-XX:+DoEscapeAnalysis 在JDK 6u23之后默认开启，配合 -XX:+EliminateAllocations 做标量替换，它干的事是：如果一个对象没逃出方法，就把对象拆成若干局部变量，直接放在栈帧或寄存器里，连堆都不用碰。
哪些写法能吃上这波优化
- 方法内 new 出来的临时对象，只在本方法读写。
- 循环里创建、循环内用完就丢的包装对象。
- 返回基本类型而非对象的中间计算结果。
吃不到的典型写法：
- 对象被赋值给成员变量或静态字段。
- 对象被作为返回值传出方法。
- 对象被放进集合或传入其他方法。
怎么确认真的生效
-XX:+PrintEscapeAnalysis
-XX:+PrintEliminateAllocationsJIT编译日志里能看到形如 ++++ eliminated 的记录，也可以用JMH跑对比，观察GC次数变化，业内专家指出，逃逸分析对分配速率的改善幅度高度依赖代码结构，别指望加上参数就万事大吉。
电商大促场景下JVM堆内存如何调优
大促的流量形态是短时暴涨、对象创建集中、生命周期极短，这种场景下调参重点和常态业务不一样。
堆大小与压缩指针上限的取舍
单机堆给到30GB左右,保住压缩指针，比给到40GB丢掉压缩指针、靠更大堆减少GC更划算，判断方法很简单：压测两套配置，看单位时间GC停顿总时长和吞吐。
收集器怎么选
- 堆16GB以内、停顿要求一般：G1够用。
- 堆32GB左右、停顿要求严格：优先考虑ZGC或Shenandoah，JDK 17之后可用性已经不错。
- 老版本JDK：G1加合理的
-XX:MaxGCPauseMillis是稳妥选择。
预触内存页
-XX:+AlwaysPreTouch启动时把堆内存页全部预分配,避免运行期缺页中断叠加在业务高峰上，代价是启动变慢、常驻内存变高，容器环境下要留意启动超时。
云服务器按量计费下64位JVM参数怎么配
按需计费的云主机,规格一旦定死，堆大小就得在“够用”和“不浪费”之间取平衡，给多了，内存成本上去；给少了，GC频繁。
堆占比的实操经验
- 整机只跑一个JVM：堆占物理内存的50%到70%。
- 同机跑其他进程：堆不超过总内存的一半。
- 容器环境：确认JDK版本在8u191或10以上，
-XX:+UseContainerSupport默认开启，JVM会读cgroup限制而非宿主机内存。
容器里可以这样验证：
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize机房与规格的地域差异
跨地域部署时,不同机房的机型内存规格梯度不同，堆参数最好抽成环境变量而不是写死在启动脚本里，华南、华东的机型选择不同，同一份 -Xmx 未必都合适，把堆大小做成启动参数模板，按环境注入，比统一配置更省事。
三个常见误区
- 堆越大越好：超过32GB丢掉压缩指针，引用宽度翻倍，实际可用对象容量未必增长。
- TLAB越大越好：单个线程浪费的空间会累积，线程数多时反而加剧Eden区碎片。
- 逃逸分析万能：只在JIT编译后的代码里生效，解释执行阶段照样走堆分配，新启动的服务别指望立刻受益。
Java虚拟机64位内存模型优化对象分配Q&A
64位JVM不开启压缩指针会有什么后果？
每个对象引用占8字节,对象头中的类型指针也占8字节，同样数量的对象，堆内存占用会明显上升，缓存命中率下降，GC扫描的引用数量不变但每个引用更宽，对于对象数量大的应用，这种影响会传导到吞吐和延迟上。
压缩指针和ZGC能一起用吗？
可以,ZGC支持压缩指针，但前提同样是堆不超过32GB（未调整对齐粒度时），开启 -XX:+UseCompressedOops 后ZGC会使用压缩的引用表示，具体可用性以对应JDK版本的官方文档为准。
TLAB调优后怎么判断是否真的有效？
看两个指标：一是 -XX:+PrintTLAB 输出中每线程的浪费比例，二是GC日志中年轻代GC的触发频率，浪费比例下降、YGC次数减少，说明TLAB尺寸与实际分配模式匹配了，若两者都没有变化，说明瓶颈不在TLAB，应该往对象生命周期和晋升行为上找原因。