mark word 什么时候为偏向状态

在Java对象头中，标记字（mark word）的偏向状态是一个关键概念。它主要出现在启用偏向锁优化的场景中，用于标识对象锁可偏向于某个特定线程，从而在无竞争时提升性能。理解其何时处于偏向状态，需深入分析对象头的结构、偏向锁的启用条件、偏向过程、撤销机制以及不同锁状态的转换时机。本文将系统剖析这些核心要点，帮助开发者掌握偏向锁的原理与应用。

       在Java虚拟机的世界中，对象在内存中的布局有一块至关重要的区域，称为对象头。对象头里存储着运行时所需的多种元数据，其中，标记字（mark word）扮演了核心角色。它如同一份对象的“身份档案”，不仅记录了对象的哈希码、垃圾回收年龄等信息，更是整个同步机制——即我们常说的“锁”——的承载者。今天，我们就来深入探讨这个标记字的一种特殊状态：偏向状态。理解它何时为偏向状态，不仅是深入理解Java并发编程底层原理的关键，更是进行高性能调优不可或缺的知识。

       首先，我们必须建立一个基础认知：标记字的状态并非一成不变。为了在并发环境中平衡性能与正确性，Java虚拟机设计了一套精巧的锁升级体系，包括无锁、偏向锁、轻量级锁和重量级锁。偏向状态，正是对应着“偏向锁”这一优化阶段。那么，第一个问题随之而来：什么是偏向锁？其设计初衷是什么？

       偏向锁是Java虚拟机针对“同步块在绝大多数情况下不仅不存在多线程竞争，而且总是由同一个线程多次获得”这一场景所做的优化。它的核心思想是：如果一个线程获得了锁，那么锁就进入偏向模式。当这个线程再次请求相同的锁时，无需再进行任何同步操作（如操作系统层面的互斥量操作），从而节省了大量涉及锁申请、释放的开销。这种将锁“偏心”地交给某个线程的做法，就是“偏向”一词的由来。根据Oracle官方文档及OpenJDK源码中的描述，引入偏向锁是为了减少在无竞争情况下的同步开销。

       理解了偏向锁的意图，我们便可以切入正题：标记字在何种宏观条件下会表现为偏向状态？答案与虚拟机配置和对象生命周期紧密相关。默认情况下，在支持偏向锁优化的Java虚拟机（如HotSpot虚拟机）中，对象在被创建之后，如果其对应的类被施加了偏向锁的“魔法”，那么该对象的标记字在初始化后便会处于一个“可偏向”但“未偏向”的匿名偏向状态。这里有一个关键点：偏向锁并非默认对所有对象启用。在Java开发工具包（JDK）的某些版本（如JDK 6及之后）中，虚拟机在启动后有一个短暂的“延迟”期，在此期间新创建的对象其标记字是无锁状态。延迟期过后，新创建对象的标记字才会初始化为可偏向的匿名偏向状态。这个延迟期可以通过虚拟机参数“-XX:BiasedLockingStartupDelay”来设置，设为0则意味着程序启动后立即启用偏向。

       接下来，我们要看一个更具体的动作：偏向状态是如何被真正“激活”的？即，一个对象从“可偏向”变为“已偏向”于某个线程的时刻。这个过程发生在某个线程第一次尝试通过同步机制（synchronized关键字）获取该对象的锁时。虚拟机检测到对象的标记字处于可偏向的匿名偏向状态，便会通过一种称为“偏向”的操作，将当前线程的线程标识等信息，以特定的编码格式，写入到对象的标记字中。一旦写入成功，对象的标记字就正式进入了“偏向状态”，并且明确指向了当前线程。此后，只要该线程再次进入这个同步块，它只需要检查标记字中的线程标识是否与自己一致。如果一致，线程便可以直接执行同步块内的代码，这个检查过程非常快速，几乎没有任何代价。

       然而，天下没有免费的午餐，偏向锁的优化建立在“无竞争”的假设上。一旦这个假设被打破，偏向状态就需要被撤销。这就引出了另一个核心问题：标记字会在什么时候失去其偏向状态？撤销偏向状态，也称为“偏向锁撤销”，是理解偏向锁状态转换的关键环节。撤销主要发生在两种场景下。第一种场景是“竞争出现”：当另一个线程尝试获取这个已经被偏向的对象的锁时。虚拟机需要撤销原线程的偏向，将锁升级为更适合处理竞争的轻量级锁状态。第二种场景是“调用了对象的哈希码相关方法”，例如调用了“hashCode()”方法。这是因为在偏向状态下，对象的标记字空间被用来存储偏向线程标识和纪元（epoch）等信息，没有足够的空间来存储一个完整的哈希码。一旦需要计算并存储哈希码，就必须撤销偏向状态，恢复到无锁状态（此时哈希码可以存入标记字）或直接升级为其他锁状态。

       撤销过程本身也值得深入探讨。偏向锁的撤销是一个安全点敏感的操作。这意味着，虚拟机通常不会在任意时刻随意撤销偏向锁，而是需要等待所有线程到达一个安全点（即线程执行到一个已知的、状态稳定的位置）后才能进行。这是因为撤销操作需要修改对象的标记字，必须保证在修改时，持有偏向锁的线程不在同步块中活跃执行，否则可能导致数据不一致。这个设计确保了撤销过程的线程安全性，但也意味着撤销操作本身有一定的开销。

       除了竞争和哈希码，还有一个机制影响着偏向状态的存续：批量重偏向与批量撤销。这是虚拟机为了应对特定场景所做的进一步优化。假设存在这样一种情况：一个类的对象被多个线程交替访问，但每个线程在短时间内都只访问其中一部分对象。如果每个对象在发生竞争时都单独经历一次偏向撤销和可能的轻量级锁升级，开销会很大。为此，虚拟机引入了“批量重偏向”机制。当某个类的对象偏向锁撤销次数达到一个阈值（如20次）时，虚拟机会认为这个类的对象虽然存在竞争，但模式并非完全不适合偏向锁。随后，虚拟机会尝试将之后对该类对象的加锁请求，直接偏向于新的请求线程，而不是先撤销再升级。而“批量撤销”则发生在撤销次数达到一个更高的阈值（如40次）时，虚拟机会认为这个类的对象完全不适合使用偏向锁，从而将该类所有对象的偏向状态禁用，之后该类的所有新实例都不会再进入偏向状态。

       我们还需要关注标记字本身的物理结构。标记字的位编码如何标识偏向状态？在常见的64位虚拟机中，一个64位的标记字，其最低的几位（通常是最低2位或3位，取决于具体实现）被用作锁标志位。例如，在HotSpot虚拟机的实现中，当最低3位为“101”时，就表示对象当前处于偏向状态。而其余的位则用来存储偏向线程的标识、偏向时间戳（epoch）等信息。这种紧凑的位编码设计，使得标记字能在有限的空间内承载丰富的状态信息。

       了解了结构，我们来看一个实践中的细节：禁用偏向锁后，标记字的状态表现。在某些高并发、锁竞争激烈的应用中，偏向锁带来的初始化开销和撤销开销可能反而会降低性能。此时，开发者或系统管理员可以通过虚拟机参数“-XX:-UseBiasedLocking”来完全禁用偏向锁。当偏向锁被禁用后，所有新创建的对象，其标记字将永远不会进入“可偏向”的匿名偏向状态，而是直接表现为无锁状态。后续任何线程对该对象加锁，都会直接走轻量级锁的加锁流程。这对于那些明确知道存在大量锁竞争的场景，是一种有效的优化手段。

       对象的年龄也会影响偏向状态吗？垃圾回收对偏向状态的影响。是的，垃圾回收过程也会与偏向状态发生交互。尤其是当进行年轻代垃圾回收（Minor GC）时，存活的对象可能会被复制或移动。在复制过程中，对象的标记字会被重新处理。如果对象原本处于偏向状态，某些垃圾回收器的实现可能会选择在此时清除其偏向状态，将其重置为无锁或匿名偏向状态（如果偏向锁仍全局启用）。这主要是为了简化处理逻辑，避免在复制后还需要维护复杂的偏向信息。

       从全局视角看，偏向锁在整个锁升级路径中的位置。它是锁升级的起点之一（另一个起点是无锁）。一个对象的锁状态，可能从无锁/可偏向开始，在第一次被线程获取时变为偏向锁。当出现竞争时，从偏向锁撤销并升级为轻量级锁。如果轻量级锁的竞争依然激烈（表现为线程自旋获取锁失败），则会进一步膨胀为开销最大的重量级锁。理解偏向状态，就是理解这条性能优化路径的第一站。

       我们还需要考虑一个时间维度：偏向锁的“时效性”：偏向时间戳的作用。在标记字的编码中，有一个称为“epoch”（纪元或时间戳）的字段。它主要用于解决批量重偏向过程中的一致性问题。类的“类元数据”中也有一个“epoch”值。当进行批量重偏向时，类的“epoch”值会递增。之后，当线程尝试偏向一个对象时，会检查对象标记字中的“epoch”是否与类的“epoch”一致。如果不一致，说明该对象的偏向信息可能已经“过时”，即使它看起来是偏向状态，也需要走一遍完整的加锁流程来重新偏向或升级。这个机制确保了批量重偏向操作的安全性。

       对于开发者而言，如何观察和验证标记字的偏向状态？虽然直接读取内存中的标记字位信息非常困难，但我们可以借助一些工具来间接观察。例如，使用OpenJDK提供的“Java对象布局工具”（JOL），可以非常方便地打印出一个对象在内存中的实际布局，包括其标记字的具体值和锁状态。通过编写测试代码，创建对象、加锁、制造竞争，并同时使用JOL工具打印对象头信息，开发者可以直观地看到标记字从无锁到偏向，再到撤销升级的整个变化过程，这对于深入理解和调试并发问题极有帮助。

       最后，我们必须以发展的眼光来看待这项技术。偏向锁在现代Java开发中的定位与未来。随着硬件的发展和软件架构的变化，尤其是容器化、微服务架构的普及，应用的并发模式也在演变。偏向锁的优化收益在某些场景下正在减小，而其固有的初始化延迟和撤销开销开始受到更多审视。事实上，在最新的JDK版本（如JDK 15及之后）中，偏向锁已经被标记为“弃用”状态，并计划在未来的版本中移除。官方认为，维护偏向锁这套复杂机制的收益，在现代多核处理器和常见的应用负载下已经不再显著。因此，对于新一代的Java开发者，理解偏向状态更多的是为了理解锁优化的历史脉络和底层思想，而在新的项目中，可能更需要关注其他更高效的并发控制手段。

       综上所述，标记字的偏向状态是一个特定历史时期和技术背景下，Java虚拟机为了极致优化单线程重复加锁场景而设计的精巧机制。它始于对象的创建与虚拟机配置，成于线程的第一次获取，终于竞争的出现或哈希码的计算，并受到批量操作、垃圾回收等多重因素影响。尽管其未来可能逐渐淡出舞台，但深入剖析其原理与时机，无疑能让我们对Java并发模型的理解更加深刻和透彻，从而在面对更复杂的性能问题时，能够做到心中有数，手中有术。

       希望这篇深入的分析，能为你揭开标记字偏向状态的神秘面纱。在并发的世界里，理解底层机制永远是迈向高性能之路的坚实一步。