Java中synchronized关键字的使用方法-java教程-PHP中文网

synchronized是Java中保证线程安全的基础机制，通过锁定对象控制多线程对共享资源的访问。它可修饰实例方法、静态方法或代码块，分别锁定当前实例、Class对象或指定对象，实现不同粒度的同步。修饰实例方法时，锁住this，同一实例的synchronized方法互斥；修饰静态方法时，锁住类的Class对象，所有实例共享该锁；使用synchronized(object)代码块可自定义锁对象，提升并发性能。相比ReentrantLock，synchronized语法简洁、自动释放锁、不易出错，且JVM已对其优化，适合大多数场景；而ReentrantLock提供公平锁、可中断、尝试获取锁等高级功能，适用于复杂并发需求。但synchronized存在性能开销，主要源于线程阻塞、上下文切换及锁升级，可通过缩小同步范围、使用并发工具类（如ConcurrentHashMap、Atomic类）或无锁编程来优化。总之，应根据实际需求权衡使用synchronized与ReentrantLock，在保证线程安全的同时兼顾性能。

java中synchronized关键字的使用方法

Java中的

synchronized

登录后复制

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

解决方案

synchronized

登录后复制

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

1. 修饰实例方法

当

synchronized

登录后复制

修饰一个非静态方法时，它锁定的是当前实例对象。这意味着，如果一个线程进入了某个对象的

synchronized

登录后复制

实例方法，那么其他线程就无法访问该对象的任何

synchronized

登录后复制

实例方法，直到前一个线程退出。

立即学习“Java免费学习笔记（深入）”；

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()

登录后复制

时，它会获取

登录后复制

这个

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

登录后复制

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

法语写作助手

法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。

查看详情

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()
```
  登录后复制
  方法在多线程环境下只创建一次实例。

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和硬件环境下可能展现出更好的性能（尽管差距在缩小）。
- 需要对锁的获取和释放有更精细的控制，例如在不同的方法中获取和释放锁。