Java关键字面试：static、volatile、synchronized等

搞 Java 的老哥们应该都有过这种体验：写了几年代码，class、new、if、for 这些关键字闭着眼都能用，可一旦被问到 volatile 和 static 到底有什么区别，或者“final 修饰的数组能不能改内容”，很多人就开始冒汗。关键字是 Java 语法的最小建筑单元，也是 Java 面试中最常翻车的一类题目。它不像框架那样一个月换一个版本，而是从 JDK 1.0 起就基本定型，所以把这个基础打扎实，性价比极高。

这篇文章我按自己的理解把 Java 里的关键字重新过了一遍，重点拆解 static、final、volatile、synchronized 这几个高频词，同时把 transient、instanceof、assert 这些容易忽略的角落也补上实战经验。无论你是准备 Java 面试，还是刚学完基础语法想查漏补缺，都应该能从里面找到自己还没注意到的细节。

1. 先给关键字分个类，再谈理解

1.1 关键字、保留字、字面常量，别混为一谈

Java 里的关键字（keyword），是指被语言本身赋予了特殊含义的标识符。从句法层面看，关键字本质上就是“被征用的标识符”，所以你不能拿它们去给类、方法或变量命名。这里要特别注意一个概念：保留字（reserved word）。Java 保留了 goto 和 const，但它俩并没有被真正使用，属于“占着位置但还没安排工作”的保留字。还有 true、false、null 严格来说不是关键字，它们是字面常量（literal），同样不能用作标识符。

很多面试题就喜欢在这个细节上挖坑，比如问“null 是关键字吗”，标准答案就是：不是关键字，是字面常量。再追问一层就是：goto 和 const 虽然不能用，但你写 const 会直接编译报错，原因就是它被保留给 Java 语言未来可能使用，只不过多年过去仍然没被启用。

我们常说的关键字数量，不同版本略有差异。JDK 9 之后模块化引入了 module、requires、exports 等一批新关键字，JDK 14 之后又有 record，JDK 17 引入了 sealed 和 permits，JDK 21 又给了 var 作为保留的局部变量类型名。注意 var 不是关键字，它属于保留类型名，只是语法上会让你感觉很像关键字。所以一个实用的做法是：遇到新版本特性，先去查官方文档的关键字列表，别凭感觉去猜“sealed 能不能当类名”，我就见过有人试了半天才发现这是新关键字。

1.2 我按用途把关键字分成七类

给关键字分类这件事，网上有各种分法，但很多都是一股脑列出来让人背。我习惯按“在代码里解决什么问题”来归组，这样每次看到一个关键字，就能立刻联想到它管的是哪一类语义。

这个分类不是官方的，但很好用。比如你看到一段代码里出现了 extends，立刻知道它在搞类型继承，再看有没有 implements，就能判断是抽象扩展还是接口实现。分类的最大价值是建立“语义索引”，而不是让你死记单词表。

1.3 理解关键字背后的编译期和运行期语义

背列表没有意义，要理解每个关键字影响的是“编译期行为”还是“运行期行为”。像 final 主要影响编译期的类型检查，volatile 影响运行期的内存语义，synchronized 影响锁的获取与释放，static 则牵扯到类加载和初始化过程。这些关键字不是独立存在的，它们组合在一起才构成 Java 的类型系统和并发模型。

举个例子，static 和 final 组合成 static final 常量，编译期就能确定值的会在字节码层面做常量替换；但如果是对象引用，依然只在运行期才确定具体指向。volatile 和 static 组合成 static volatile，则是实现多线程共享状态标志的经典写法。所以当你看到一个“组合用法”，不要只记结论，要习惯性拆开想：每个关键字在被 javac 编译时做了什么检查，在 JVM 运行时又做了什么约束。养成这个习惯后，很多看似玄学的问题都能自己推导出来。

2. 高频面试三剑客：static、final、volatile

2.1 static：类级别的一切

static 的中文翻译是“静态”，但更好的理解是“类级别”。被 static 修饰的成员不依赖某个具体实例存在，它属于整个类，所有实例共享同一份数据。先看用法：

• static 变量：类加载时就分配内存，所有实例访问到的是同一个变量，常用于常量定义和全局共享状态。
• static 方法：可以在没有实例的情况下直接调用，方法内部不能直接访问非静态成员，因为没有 this 可以指代。
• static 代码块：在类加载的初始化阶段执行，且只执行一次，适合做静态资源的预加载。
• static 内部类：不会隐式持有外部类的引用，相比普通内部类可以避免内存泄漏。
• import static：静态导入，可以把工具类的静态方法直接引进当前文件，比如 import static java.lang.Math.max。

写一段最典型的代码：

java复制public class Counter {
    public static int count = 0;
    private static final int MAX_COUNT = 100;

    static {
        System.out.println("Counter class loaded, MAX_COUNT = " + MAX_COUNT);
    }

    public static void increment() {
        count++;
    }

    public static int getCount() {
        return count;
    }
}

这里有几个很容易被忽视的细节。第一，static 变量的生命周期跟类一样长，从类加载诞生，到类卸载才消亡，比普通实例长得多。所以在服务端项目里，如果一个 static 集合不加控制地往里面放数据，多少次 Full GC 都释放不掉，这就是典型的“静态集合导致内存泄漏”。我见过一个老系统把用户会话挂在 static HashMap 里，最后只能靠定时重启续命。

第二，static 方法能不能被重写？不能。子类里写一个签名相同的方法，叫“隐藏”（hiding）而不是“重写”（override），动态绑定不会生效。换句话说，用父类引用调用这个方法时，调用的还是父类的版本。很多人在面试时脱口而出“可以重写”，实际上是踩了隐藏和重写的概念坑。代码上可以这样验证：

java复制class Parent {
    static void hello() {
        System.out.println("parent");
    }
}

class Child extends Parent {
    static void hello() {
        System.out.println("child");
    }
}

public class Demo {
    public static void main(String[] args) {
        Parent p = new Child();
        p.hello(); // 输出 parent，不是 child
    }
}

第三，static 块和实例初始化块的执行顺序不同。static 块只在类加载时跑一次，实例初始化块每次 new 都会执行，并且先于构造方法。如果类里有继承关系，父类静态块先于子类静态块执行，这些都是 JVM 类加载机制的一部分，面试问“类初始化顺序”时经常和这些关键字绑在一起出题。

2.2 final：不可变到底是什么不可变

final 最容易被误解成“完全不可变”，但实际上它只约束“引用”和“值”的层级。具体来说：

• final 修饰基础类型变量：变量只能被赋值一次，之后不能再改值。
• final 修饰引用类型变量：引用地址不能再指向其他对象，但对象内部的内容可以随便改。
• final 修饰方法：方法不能被子类重写，但可以被重载。
• final 修饰类：类不能被继承，比如 String 就是 final 的。
• final 修饰方法参数：参数在方法内部不能被重新赋值。

直接看例子，这个例子是我在面试里经常拿来问候选人的：

java复制public final class Config {
    public final String name = "app";
    private final int[] values = new int[]{1, 2, 3};

    public void mutate() {
        values[0] = 99;           // 编译通过，数组内容可以改
        // values = new int[]{4, 5, 6};  // 编译报错，引用不能改
    }
}

看到没有，final 数组的引用不能重新赋值，但数组里的元素照样能改。所以要让一个对象真正不可变，单单加 final 远远不够，还得把字段全部设为 private final、不提供修改内容的 setter、必要时用 Collections.unmodifiableList 包装返回值。

进阶一点的内容是 final 在 Java 内存模型（JMM）里的“冻结”语义：final 字段在构造器里完成赋值之后，JVM 会保证其他线程读取这个字段时，不需要额外同步就能看到正确值，前提是构造函数里不能把对象引用泄漏出去，也就是不能发生 this 逸出。这就是为什么不可变对象天然是线程安全的，很多并发场景里把对象设计成 final 字段就是利用这一点。

还有一个实际开发中的细节：final 修饰的字段如果是编译期常量，比如 static final int MAX = 10，在编译阶段就会直接替换成字面量，所以对 MAX 的读取不会等到运行期。但如果是 static final 引用类型，比如 static final List<String> LIST = new ArrayList<>()，它仍然是一个普通对象引用，只是引用不能变，列表内容可以变。这一点在做配置管理时特别容易搞混，以为常量对象就是不可变，结果多个线程往里面写数据，直接埋雷。

2.3 volatile：可见性、有序性，但不含原子性

volatile 是并发关键字里被问得最多的一个，也是最容易被一句话带过的。它解决两个问题：可见性和有序性。

先说可见性。每个线程在 Java 内存模型下都有自己的工作内存，读变量时会先把主内存的值拷到工作内存，后续读到的可能是自己工作内存里的旧值。如果一个线程改了变量，另一个线程可能长时间看不到这个变化，这就是可见性问题。volatile 的作用是：写操作会强制把修改刷回主内存，读操作会失效本地缓存重新从主内存拿，从而保证一个线程的修改对其他线程立即可见。

一个经典且正确的用法是状态标志：

java复制public class FlagHolder {
    private volatile boolean running = true;

    public void stop() {
        running = false;
    }

    public void run() {
        while (running) {
            // do something
        }
    }
}

如果 running 不加 volatile，stop() 在另一个线程执行后，run() 所在线程可能永远读不到新值，程序就卡死在循环里。加了 volatile 后，修改立刻立竿见影。

再说有序性。JVM 和 CPU 为了优化性能，会允许指令重排序，只要重排序后的结果对单线程一致。但在多线程下，重排序可能导致一个线程“看到”另一个线程的操作顺序跟代码顺序不一致。volatile 通过插入内存屏障来禁止特定类型的重排序，典型应用就是单例的双重检查锁（DCL）。

java复制public class Singleton {
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

这里 instance 不加 volatile 会出大问题。new Singleton() 在底层要分三步：分配内存、调用构造器初始化对象、把引用赋值给 instance。如果有一步重排序成了“先赋值引用，再调用构造器”，另一个线程就会拿到一个构造器还没执行完的对象，表现为拿到半初始化的实例。volatile 的作用就是禁止赋值引用这一步跟构造器初始化发生重排序。

但是 volatile 有一个非常重要的边界：它不保证原子性。最经典的错误就是用它做计数器：

java复制private volatile int count = 0;

public void increase() {
    count++; // 不是原子操作
}

count++ 实际上是“读-加-写”三步操作，volatile 只能让每一步的读写立刻可见，不能保证这三步之间没有被其他线程插入操作。并发执行 increase()，最终结果一定小于预期值。这种场景应该用 AtomicInteger，或者直接上 synchronized。

我把 volatile 和 synchronized 放到一张表里对比，面试时你能把这个表讲清楚，基本就过了：

我还想补充一个容易出错的组合：volatile 和 static。有人以为加了 static volatile 就能解决所有并发问题，其实并发问题的本质是“多线程操作共享可变状态”，如果这个状态是一个集合或者一个复合对象，volatile 只能保证引用本身可见，不能保证对象内部的字段安全。

3. 并发、序列化与那些容易被忽略的关键字

3.1 synchronized：锁住的是什么

synchronized 是 Java 内建的关键字级别的锁，它有三种用法，锁的对象完全不同：

• 修饰实例方法：锁的是当前实例 this，同一个实例的相同方法互斥，不同实例之间不互斥。
• 修饰静态方法：锁的是该类的 Class 对象，所有实例共享同一把锁。
• 修饰代码块：可以指定任意对象作为锁，粒度更细，灵活性最高。

java复制public class SyncDemo {
    private final Object lock = new Object();

    public synchronized void methodA() {
        // 锁 this
    }

    public static synchronized void staticMethod() {
        // 锁 SyncDemo.class
    }

    public void methodB() {
        synchronized (lock) {
            // 锁 lock 对象
        }
    }
}

一个很容易被忽视的点是：实例方法和静态方法之间不会互斥，因为它们锁的对象不一样。假设同一个类里有一个 synchronized 实例方法和一个 synchronized 静态方法，两个线程分别调用它们，可以并行执行，不存在竞争。很多刚接触并发的同事在这里栽过跟头，以为类上所有 synchronized 都互斥，结果线上出现预期外的并发执行，排查半天才找到原因。

JDK 6 之前，synchronized 因为底层直接依赖监视器锁，性能比较重，所以在很多文章里被说成“重量级锁”。JDK 6 之后引入了锁升级机制：无锁状态到偏向锁，偏向锁在出现竞争时升级为轻量级锁，轻量级锁竞争加剧再升级为重量级锁。这个升级是单向的，重量级锁不会主动降级。理解这个机制对调优有一定帮助，但我更想提醒的是锁对象选择的问题。

千万不要拿字符串字面量或者 Integer 缓存对象当锁。比如 synchronized (Integer.valueOf(1))，看起来锁的是局部值，实际上多个地方可能锁到同一个缓存对象上，造成无谓的阻塞甚至死锁。字符串字面量还有常量池这个坑，两个不相关的类如果用了同样的字符串常量，锁就互相串了。我自己写代码时，只使用私有 new Object() 作为锁对象，或者直接用类的 Class 对象，明确且可控。

3.2 transient：序列化时不想带上的字段

transient 这个关键字平时用得少，但一旦涉及跨网络传输、缓存存储、对象落盘，就必须搞清楚它。它的作用是告诉默认序列化机制：这个字段不参与序列化，不要写进序列化流里。

典型场景有：密码、密钥、临时 token、大数据量的缓存字段，以及那些可以从其他字段推导出来的冗余数据。看个例子：

java复制public class User implements Serializable {
    private static final long serialVersionUID = 1L;

    private String name;
    private transient String password;
    private transient String token;
}

这样序列化 User 对象时，name 会被写入，password 和 token 不会。反序列化回来后，transient 的引用类型字段是 null，基本类型字段是默认值 0 或 false。如果你希望反序列化后恢复一些敏感信息，就得手动实现 writeObject 和 readObject 方法，在恢复时从配置中心或者密钥服务重新拉取。

还有一个细节：静态字段不管加不加 transient，默认序列化都不会写进流里，因为它属于类而不是实例。所以有些人以为给静态字段加 transient 有用，其实不加也一样。

更隐蔽的一个坑是 transient 和 final 同时使用。在部分老 JDK 版本中，final transient 字段的反序列化表现和普通 transient 字段不同，容易出现兼容性问题，导致不同 JDK 版本之间序列化结果不一致。我的建议是在设计 DTO 时直接避开这种组合，能用可控的 setter 恢复，就别把 final 和 transient 绑在一起。

3.3 instanceof、assert、native、strictfp：冷门但不冷

instanceof 是类型判断运算符，用来判断一个对象是不是某个类型，或者实现了某个接口。有两个细节值得说：第一，null instanceof 任何类型都返回 false，不会抛空指针异常，所以不用先判空再判断类型；第二，JDK 16 开始支持模式匹配，判断完可以直接绑定变量，省掉一次强转：

java复制if (obj instanceof String s) {
    System.out.println(s.length());
}

这种写法比老式的 if (obj instanceof String) { String s = (String) obj; } 清爽很多，也减少了手工强转时写错类型的机会。

assert 关键字是断言，默认情况下不生效，必须在 JVM 启动参数里加 -ea 才会开启。这里的坑在于，很多人把 assert 当成生产环境的参数校验工具来用，结果线上环境没开 -ea，断言全部被跳过，该拦截的非法参数全部放过去了。我一直认为 assert 更适合在测试阶段和开发阶段用来表达“这里的状态绝不可能是这个值”，生产代码里的参数校验应该用 Objects.requireNonNull、IllegalArgumentException 或者专门的校验框架。

native 关键字用来声明 JNI 方法，表示这个方法的实现不在 Java 层，而是由本地代码实现。日常写业务代码几乎碰不到，但 Object.hashCode() 的某些 JVM 实现、System.currentTimeMillis() 底层都有 native 方法。理解它的存在有助于读懂 JVM 相关源码。

strictfp 则用来强制浮点运算在不同平台上结果一致。在老 JDK 里，如果不加 strictfp，虚拟机可以利用 CPU 的扩展精度让浮点结果更精确，代价是不同平台结果可能不同。加了它之后，所有浮点运算都严格遵循 IEEE 754 标准。JDK 17 里它被标记为 obsolete，但我建议跨平台数值计算工具类仍然保留它，省得不同机器上跑出不一样的小数。

4. 实操中踩过的坑与排查技巧

4.1 高频问题速查表

下面这些问题，都是我实际排查或者帮别人排查时遇到过的，整理成一张速查表，遇到类似症状可以直接对着看：

4.2 面试八股里最容易说错的三句话

第一句：“static 方法可以被重写。”严格说不是重写，而是隐藏。虽然子类里可以定义同名静态方法，但方法分派在编译期就确定了，父类引用调用时还是父类的版本。你只有用子类引用调用时才会“看起来像覆盖”。面试时如果能把隐藏和重写的概念区别讲清楚，会显得基本功特别扎实。

第二句：“final 修饰的变量不能改变。”这个话太粗糙，要拆成两层来说。基础类型变量不能改值，引用类型变量不能改引用地址，但引用指向的对象内容可以变，对象是否真正不可变还取决于类的设计。面试官抛出“final 数组能不能改”时，能答出“引用不能改，但数组内容可以改”才算过关。

第三句：“volatile 和 synchronized 都能保证原子性。”这是完全错误的。synchronized 靠互斥保证原子性，volatile 只保证可见性和有序性，不保证复合操作的原子性。如果面试时能先把原子性、可见性、有序性分别讲清楚，再给出一两个适用场景加一个错误示例，这道题基本上就是加分项。

4.3 我写代码的一些个人习惯

从实战角度看，我有几条跟关键字相关的小习惯，每次带新人都强烈建议他们养成：

方法参数和局部变量能加 final 就加 final。这看起来有点啰嗦，但能防止后续维护时不小心把参数重新赋值，让代码意图更清晰。尤其在 Java 8 之后，lambda 表达式要求捕获的变量必须是 effectively final，提前养成习惯能少踩很多编译错误。

static 常量统一用大写加下划线的命名规范，并且一定要加 final。static 非 final 的可变字段是共享状态隐患，能不用就不用，真要用也尽量限制在工具类内部，并提供同步入口。

锁对象只选择我们自己 new 出来的私有 Object，尽量不锁 this、不锁类对象，更不锁字符串字面量。这样可以把锁的可见范围控制到最小，避免外部代码无意中复用同一个锁对象造成死锁或性能问题。

只要一个类实现了 Serializable，第一件事就是声明 serialVersionUID。没声明时 JVM 会根据类结构自动生成一个版本号，一旦你改了类结构，比如加了一个字段，老数据反序列化时版本号就对不上，直接报 InvalidClassException。这种问题往往还不好复现，因为本地测试用的序列化数据和线上不一致。手动声明版本号是成本最低的规避方式。

4.4 顺带提醒：别把 Java 关键字当标识符的零碎坑

命名时最容易犯的错是把 Java 关键字、保留字当成变量名。常见的包括：给类取名叫 Class、给变量取名 New、给方法取名 Switch，这些都会直接编译报错。还有一类是业务上更容易遇到的坑：数据库字段名恰好是 MySQL 的保留字，比如 order、desc、select、group，Java 类里叫 order 没问题，但 MyBatis 生成 SQL 时如果不加反引号处理，SQL 直接报语法错误。虽然这不算 Java 关键字本身的问题，但排查现场时经常把矛头指向 Java 层，实际上问题出在数据库方言上。

Java 关键字作为标识符的规则非常严格，切忌用拼音加数字去硬凑，比如 new1、class2 这种命名虽然编译能过，但可读性极差。在团队协作里，命名规范比某个具体语法技巧更能决定代码质量，关键字相关的命名规则只是其中很小的一环，但出了问题往往也是最难看出来的一环。

整体过一遍之后你会发现，Java 关键字本身并不难，难的是每个关键字背后关联的那套编译和内存语义。我在实际排查问题时最深的感触是：很多线上诡异问题最后都归结到 volatile 可见性、static 变量生命周期、synchronized 锁对象选择这些底层基本功上。框架可以换，版本可以升，但这些关键字的规则十几年没大变，花这点时间把地基打牢，比追新特性更划算。最后再分享一个小技巧：如果实在记不住某个关键字的边界，自己写一个几十行的最小示例，亲手编译、运行、看结果，比对着文档背十遍都管用。希望这篇内容能帮你把这些“老朋友”真正变成自己的武器。