直接指针方式更有利于维持高吞吐量，因其访问路径短、缓存友好，配合写屏障等机制可并发更新引用，避免stw和多次访存开销；句柄寻址虽简化移动操作，但引入双跳访问、句柄表写竞争及局部性差等问题，反而降低吞吐量。
在高频垃圾回收且对象频繁移动的场景下，句柄寻址对系统整体吞吐量的贡献更小，而直接寻址（即直接指针方式）实际更有利于维持高吞吐量。
这不是直觉上“句柄更灵活所以更好”的问题，而是要结合吞吐量定义和GC行为综合判断：
吞吐量 = 执行用户代码的时间 /（执行用户代码的时间 + GC时间）
——关键在于减少GC停顿时间、降低访问开销、避免引用批量更新。
句柄寻址在移动对象时的优势不等于高吞吐量优势
- ✅ 移动对象时，只需更新句柄表里的数据指针，reference本身不用改，适合标记-整理类GC。
- ❌ 但每次对象访问需两次跳转：reference → 句柄表 → 实际对象；
- ❌ 句柄表本身是额外内存结构，增大缓存压力，访问局部性差；
- ❌ 高频GC意味着更频繁的对象移动，也意味着句柄表被高频写入，可能引发写竞争或缓存失效。
直接指针方式虽需更新引用，但现代JVM已高效化解该成本
- ✅ 访问路径最短：reference → 对象头，一次解引用，CPU缓存友好，指令级效率高；
- ✅ HotSpot实际采用此方式，配合写屏障（Write Barrier）+ 卡表（Card Table）+ 并发/增量更新机制，在对象移动（如G1、ZGC的重定位阶段）时，能异步或并发地修正引用，避免STW期间集中扫堆；
- ✅ 吞吐量敏感场景（如服务器应用）优先保障用户线程执行效率，减少每条字节码的间接开销，积少成多影响显著。
高频移动 ≠ 高频全堆扫描
真正影响吞吐量的，不是“是否要改引用”，而是：
- 引用更新是否阻塞用户线程（STW vs 并发）；
- 对象访问是否引入额外延迟（1次 vs 2次访存）；
- 内存布局是否利于预取与缓存命中。
直接指针配合现代GC算法（如ZGC的彩色指针、Shenandoah的Brooks pointer），已把“移动时修引用”的开销摊薄到微秒级，而句柄的固定双跳开销却是每次必付。
所以，在真实高吞吐场景中，直接指针是更优选择——它用可控的、分散的更新成本，换来了持续稳定的低延迟访问，最终支撑更高吞吐量。
