当前位置：首页 > 文章列表 > 文章 > java教程 > synchronized关键字用法与实例解析

synchronized关键字用法与实例解析

2026-03-02 21:05:20 0浏览收藏

synchronized是Java并发编程中保障线程安全的核心机制，它通过对象锁（实例锁、Class锁或自定义锁）精准控制多线程对共享资源的互斥访问，既支持方法级粗粒度同步，也支持代码块级细粒度锁定，兼顾简洁性与可靠性；虽存在线程阻塞、锁升级等性能开销，但借助缩小同步范围、选用ConcurrentHashMap/Atomic类等并发工具，或按需切换至ReentrantLock以获取公平性、可中断性等高级能力，开发者可在安全性与高性能之间灵活权衡——掌握其原理与适用边界，正是写出健壮高效并发代码的关键起点。

Java中synchronized关键字的使用方法

Java中的synchronized关键字，在我看来，是并发编程领域里一个既基础又极其重要的概念，它主要用来解决多线程环境下共享资源的访问冲突问题，确保数据的一致性和线程安全。简单来说，它就像一个“看门人”，在同一时刻只允许一个线程进入特定的代码区域（临界区），从而避免了竞态条件和数据损坏。

解决方案

synchronized关键字的使用主要有两种形式：修饰方法和修饰代码块。

1. 修饰实例方法

当synchronized修饰一个非静态方法时，它锁定的是当前实例对象。这意味着，如果一个线程进入了某个对象的synchronized实例方法，那么其他线程就无法访问该对象的任何synchronized实例方法，直到前一个线程退出。

public class Counter {
    private int count = 0;

    // 锁定当前Counter实例
    public synchronized void increment() {
        count++;
        System.out.println(Thread.currentThread().getName() + " incremented to " + count);
    }

    public synchronized int getCount() {
        return count;
    }

    // 这是一个非同步方法，可以被其他线程同时访问
    public void doSomethingElse() {
        System.out.println(Thread.currentThread().getName() + " is doing something else.");
    }
}

在这个例子中，increment和getCount方法都加了synchronized。当一个线程调用c.increment()时，它会获取c这个Counter对象的锁。其他线程如果想调用c.increment()或c.getCount()，就必须等待。但它们可以同时调用c.doSomethingElse()，因为那个方法没有同步。

2. 修饰静态方法

当synchronized修饰一个静态方法时，它锁定的是当前类的Class对象。这意味着，无论创建了多少个该类的实例，在任何时刻，只有一个线程可以访问该类的任何synchronized静态方法。

public class StaticCounter {
    private static int staticCount = 0;

    // 锁定StaticCounter.class对象
    public static synchronized void staticIncrement() {
        staticCount++;
        System.out.println(Thread.currentThread().getName() + " static incremented to " + staticCount);
    }

    public static synchronized int getStaticCount() {
        return staticCount;
    }
}

这里，staticIncrement和getStaticCount锁定的是StaticCounter.class这个唯一的Class对象。

3. 修饰代码块

synchronized代码块允许我们更精细地控制锁的范围。它需要一个明确的锁对象。

public class BlockCounter {
    private int count = 0;
    private final Object lock = new Object(); // 专门用于同步的锁对象

    public void increment() {
        synchronized (lock) { // 锁定lock对象
            count++;
            System.out.println(Thread.currentThread().getName() + " block incremented to " + count);
        }
    }

    public int getCount() {
        synchronized (lock) {
            return count;
        }
    }

    // 也可以锁定this对象，效果与修饰实例方法类似
    public void incrementWithThis() {
        synchronized (this) { // 锁定当前BlockCounter实例
            count++;
            System.out.println(Thread.currentThread().getName() + " block with this incremented to " + count);
        }
    }

    // 锁定Class对象，效果与修饰静态方法类似
    public void incrementWithClass() {
        synchronized (BlockCounter.class) { // 锁定BlockCounter.class对象
            count++;
            System.out.println(Thread.currentThread().getName() + " block with class incremented to " + count);
        }
    }
}

使用代码块的好处是，我们可以将同步的范围限制在真正需要同步的代码上，而不是整个方法，这通常能提高并发性。选择哪个对象作为锁也很关键：

实例对象 (this或自定义对象): 保护实例的共享数据。
Class对象 (ClassName.class): 保护静态的共享数据。

`synchronized` 关键字可能带来的性能开销有哪些，以及如何规避？

使用synchronized固然能保证线程安全，但它并非没有代价，尤其是在高并发场景下，性能问题往往会浮现。在我看来，这主要源于其阻塞机制和JVM对锁的维护。

首先，最直接的开销就是线程阻塞和上下文切换。当一个线程试图获取已经被其他线程持有的synchronized锁时，它会被阻塞，并可能进入等待状态。JVM需要将该线程挂起，并在锁释放后唤醒它。这一系列的调度操作，包括线程状态的切换、CPU寄存器内容的保存和恢复，都是有时间成本的。如果锁竞争激烈，这种开销会显著增加。

其次，锁的膨胀和升级也是性能开销的一部分。JVM为了优化synchronized，引入了偏向锁、轻量级锁和重量级锁。在低竞争或无竞争时，锁的开销很小（偏向锁、轻量级锁）；但一旦出现竞争，锁就会升级为重量级锁，这涉及到操作系统级别的互斥量（mutex），其开销相对较大。虽然JVM会自动处理这些，但频繁的锁升级和降级本身也会消耗资源。

那么，如何规避这些性能问题呢？

缩小同步代码块的范围（Fine-Grained Locking）：这是最常用也最有效的策略。只对真正需要保护的共享资源进行同步，而不是整个方法。例如，如果一个方法中只有几行代码涉及到共享变量，就只同步这几行，而不是整个方法。这能最大程度地减少锁持有的时间，从而降低线程阻塞的概率。

// 不推荐：整个方法都同步，即使大部分代码不涉及共享资源
public synchronized void processData() {
    // 大量不涉及共享资源的代码...
    sharedResource.update(); // 只有这一行需要同步
    // 大量不涉及共享资源的代码...
}

// 推荐：只同步必要的部分
public void processDataOptimized() {
    // 大量不涉及共享资源的代码...
    synchronized (sharedResourceLock) {
        sharedResource.update();
    }
    // 大量不涉及共享资源的代码...
}

使用java.util.concurrent包下的并发工具：Java并发包提供了比synchronized更灵活、更细粒度的并发控制工具，例如ReentrantLock、ReadWriteLock、Semaphore、ConcurrentHashMap等。
- ReentrantLock：在某些高并发场景下，其性能可能优于synchronized，因为它提供了更丰富的特性，如公平锁、尝试获取锁、可中断锁等。
- ReadWriteLock：允许多个读线程同时访问共享资源，但写线程是独占的。这对于读多写少的场景能显著提升性能。
- ConcurrentHashMap：它内部通过分段锁机制，允许对Map的不同部分进行并发修改，而不是锁定整个Map，极大地提高了并发度。
避免不必要的同步：有时候，我们可能会过度同步。在确保线程安全的前提下，检查是否所有synchronized都是必需的。例如，如果一个变量只在一个线程中被修改，或者它的值是不可变的，那么就无需同步。
无锁编程（Lock-Free Programming）：对于一些特定的场景，可以考虑使用Atomic类（如AtomicInteger、AtomicLong）进行无锁操作。它们底层利用了CAS（Compare-And-Swap）指令，通过硬件支持实现原子性操作，避免了锁的开销。但这通常更复杂，需要更深入的理解。

总的来说，synchronized是一个可靠的工具，但它并非万能药。在追求高性能的并发应用中，我们需要对其潜在的开销保持警惕，并根据具体情况选择最合适的同步策略。

理解 `synchronized` 在不同锁定范围（方法、代码块）下的行为差异与适用场景？

理解synchronized在不同锁定范围下的行为差异，是掌握其精髓的关键。这不仅仅是语法上的区别，更关乎到你如何设计并发程序，以及如何平衡线程安全与并发性能。在我看来，这里面蕴含着对“锁粒度”的考量。

1. 修饰实例方法 (public synchronized void methodA()) 或 synchronized(this) 代码块

锁定对象： 当前实例对象（this）。
行为： 当一个线程访问某个实例的synchronized实例方法或synchronized(this)代码块时，它会获取该实例的锁。此时，该实例的其他synchronized实例方法或synchronized(this)代码块都无法被其他线程访问。
并发性： 不同的实例对象之间互不影响，可以并发执行其synchronized方法。但同一个实例内部，所有synchronized方法是互斥的。
适用场景：
- 保护实例特有的共享数据。例如，一个Account对象的余额，每个Account实例有自己的余额，不同账户之间的操作是独立的。
- 当一个方法中的大部分操作都涉及到实例的共享状态时，修饰整个方法可能更简洁。

2. 修饰静态方法 (public static synchronized void staticMethodA()) 或 synchronized(ClassName.class) 代码块

锁定对象： 当前类的Class对象。
行为： 无论创建了多少个该类的实例，甚至没有创建实例，只要有线程访问该类的synchronized静态方法或synchronized(ClassName.class)代码块，它就会获取该类的Class对象的锁。此时，该类的所有synchronized静态方法或synchronized(ClassName.class)代码块都无法被其他线程访问。
并发性： 任何线程在任何实例上，都无法同时访问该类的任何synchronized静态方法。这是一种全局锁的性质。
适用场景：
- 保护静态的共享数据。例如，一个全局计数器，所有实例共享同一个计数器变量。
- 实现单例模式中的懒汉式加载，确保getInstance()方法在多线程环境下只创建一次实例。

3. synchronized(object) 代码块（锁定自定义对象）

锁定对象： 指定的任意对象object。
行为： 线程获取的是object的锁。其他线程如果想获取同一个object的锁，就必须等待。
并发性： 这种方式提供了最大的灵活性。你可以根据需要创建多个锁对象，每个锁对象只保护它所关联的那部分共享资源。这样，不相关的共享资源可以独立地被并发访问，从而提高整体并发度。
适用场景：
- 细粒度锁定： 当一个类中有多个独立的共享资源，且它们之间没有关联时，可以为每个资源创建独立的锁对象，实现更细粒度的控制，避免不必要的阻塞。
```
public class DataProcessor {
    private List<String> listA = new ArrayList<>();
    private List<String> listB = new ArrayList<>();
    private final Object lockA = new Object();
    private final Object lockB = new Object();

    public void addToListA(String item) {
        synchronized (lockA) { // 只锁定listA
            listA.add(item);
        }
    }

    public void addToListB(String item) {
        synchronized (lockB) { // 只锁定listB
            listB.add(item);
        }
    }
}
```
  在这个例子中，addToListA和addToListB可以同时被不同的线程调用，因为它们锁定了不同的对象。
- 当需要同步的代码块不属于当前对象，或者需要跨越多个对象进行同步时。
- 避免将锁暴露给外部，使用private final的锁对象是一种良好的实践。

选择哪种锁定方式，关键在于你想要保护什么，以及希望达到怎样的并发程度。锁定实例方法或this通常用于保护对象自身的完整性，而锁定Class对象则用于保护类的静态状态。最灵活的synchronized(object)代码块则允许你根据实际情况，精确地控制锁的粒度，从而在线程安全和并发性能之间找到最佳平衡点。

`synchronized` 与 `java.util.concurrent.locks.ReentrantLock` 在功能和灵活性上的权衡考量。

在Java并发编程中，synchronized和ReentrantLock都是实现互斥同步的重要手段。它们都能确保在同一时间只有一个线程访问临界区，防止数据不一致。然而，在实际应用中，我们常常需要权衡它们的优缺点，根据具体需求做出选择。在我看来，这两种锁机制各有千秋，并没有绝对的优劣之分。

synchronized 的特点：

内置性与简洁性： synchronized是Java语言的关键字，由JVM隐式管理锁的获取和释放。它的语法相对简单，不需要手动创建锁对象，也不需要显式地调用lock()和unlock()方法。这减少了程序员出错的可能性，特别是忘记释放锁导致死锁或资源泄露的问题。
自动释放： 无论同步代码块正常执行完毕还是抛出异常，JVM都会确保锁被自动释放。这是它最大的优点之一，让代码更健壮。
可重入性： 一个线程可以重复获取它已经持有的锁。例如，一个synchronized方法可以调用另一个synchronized方法，只要它们都锁定同一个对象，不会导致死锁。
性能演进： JVM对synchronized的实现一直在优化，从早期的重量级锁（基于操作系统互斥量）发展到偏向锁、轻量级锁、自旋锁等，在很多场景下，其性能已经非常接近甚至超越ReentrantLock。

ReentrantLock 的特点：

灵活性与功能扩展： ReentrantLock是java.util.concurrent.locks包下的一个类，它提供了比synchronized更丰富的特性：
- 公平性选择： 可以在构造函数中指定是否为公平锁（new ReentrantLock(true)）。公平锁会按照请求的顺序授予锁，而非公平锁则允许“插队”，通常非公平锁的吞吐量更高。
- 尝试获取锁 (tryLock())： 允许线程尝试获取锁，如果获取不到，可以立即返回，而不是一直阻塞。这对于避免死锁和实现更复杂的并发策略非常有用。
- 可中断锁 (lockInterruptibly())： 线程在等待锁的过程中可以被中断，这对于处理长时间等待锁的场景非常重要，可以避免无限期等待。
- 条件变量 (newCondition())： ReentrantLock可以与多个Condition对象配合使用，实现更精细的线程间通信（await()/signal()/signalAll()），这比Object的wait()/notify()/notifyAll()更加灵活。
- 锁的查询： 提供了isLocked(), isHeldByCurrentThread(), getQueueLength()等方法，可以获取锁的状态信息。
手动管理： 需要显式地调用lock()和unlock()方法。这意味着你必须在finally块中确保unlock()被调用，否则可能导致锁无法释放，进而引发死锁。
```
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // 临界区代码
} finally {
    lock.unlock(); // 必须在finally块中释放锁
}
```

权衡考量与选择：

简单场景优先synchronized： 如果你的同步需求比较简单，只需要基本的互斥功能，且不涉及复杂的条件等待、非阻塞尝试获取锁等，那么synchronized无疑是更简洁、更安全的选择。它的自动管理特性减少了出错的可能。
复杂场景考虑ReentrantLock： 当你需要更高级的锁功能时，比如：
- 需要实现公平锁。
- 需要尝试非阻塞地获取锁，或者在等待锁时能够响应中断。
- 需要多个条件变量来协调不同的线程等待/通知逻辑。
- 在极端高并发且锁竞争激烈的场景下，ReentrantLock在某些JVM和硬件环境下可能展现出更好的性能（尽管差距在缩小）。
- 需要对锁的获取和释放有更精细的控制，例如在不同的方法中获取和释放锁。

我的看法：

我个人觉得，对于大多数日常开发任务，synchronized已经足够胜任，而且其简洁性带来的好处往往大于ReentrantLock的灵活性。JVM在synchronized上的优化投入是巨大的，使得它在许多场景下的性能表现非常出色。只有当你明确知道自己需要ReentrantLock提供的特定高级功能时，才应该考虑使用它。过度使用ReentrantLock，如果处理不当，反而可能引入新的bug，比如忘记释放锁。所以，选择哪个，更多的是一种“按需取用”的哲学，而不是盲目追求“更高级”或“性能更好”的工具。

好了，本文到此结束，带大家了解了《synchronized关键字用法与实例解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！

java