写出高性能Java代码，synchronized使用的三个关键问题全解析

关注

原创最新推荐文章于 2026-06-05 11:43:54 发布 985 阅读 AI 写同款· GEO 优化 ›

java深入理解synchronized 消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。阅读详情

在这里插入图片描述

🍅 作者简介：哪吒，优快云2021博客之星亚军🏆、新星计划导师✌、博客专家💪

🍅 哪吒多年工作总结：Java学习路线总结，搬砖工逆袭Java架构师

🍅 点击文末名片，关注公众号【哪吒编程】，回复 1024 ，获取《10万字208道Java经典面试题总结(附答案)》2024修订版pdf，背题更方便，一文在手，面试我有

在我十年的Java开发生涯中，亲眼目睹过无数由synchronized使用不当导致的系统灾难：从莫名其妙的数据错乱，到令人头痛的性能瓶颈，再到那些让整个团队通宵排查的神秘死锁。这些问题往往在开发环境中难以复现，却在生产环境中肆意妄为，给业务带来严重影响。

今天，我将揭开synchronized使用中最常见的三个问题，通过真实案例帮助你彻底理解这些陷阱，并掌握对应的解决方案。

在这里插入图片描述

一、锁对象与被保护资源不匹配

准备在开发一个多线程计数器服务，需要让多个线程安全地递增同一个计数器，使用synchronized关键字来保护共享资源。

public class CounterService {
    private int counter = 0;
    
    public void incrementCounter() {
        // 每次调用都创建新的锁对象
        Object lock = new Object();
        synchronized(lock) {
            counter++;  // 看似加锁，实际无保护效果
        }
    }
    
    public int getCounter() {
        return counter;
    }
}

在修改counter时使用了synchronized块。然而，实际运行时发现计数器的值非常混乱，与预期完全不符。

问题就在于锁对象的选择上。

在这段代码中，每次调用incrementCounter()方法都会创建一个全新的lock对象。这就好比每个人进入同一个房间时都带着自己的钥匙，而不是使用同一把钥匙来控制入口 - 自然无法起到互斥的作用！

要解决这个问题，我们需要确保所有线程使用相同的锁对象：

public class CounterService {
    private int counter = 0;
    private final Object lock = new Object(); // 使用一个一致的锁对象
    
    public void incrementCounter() {
        synchronized(lock) {
            counter++;
        }
    }
    
    public int getCounter() {
        synchronized(lock) { // 读取操作也需要加锁
            return counter;
        }
    }
}

所有线程现在都是使用同一个“lock对象”来控制对计数器的访问。对读取操作加了锁，这确保了读取操作能够看到其他线程的最新修改，解决了可见性问题。

在实际项目中，这种改进可能看起来微小，但却能彻底解决由于锁选择不当导致的竞态条件，在并发环境下避免出错。

二、锁粒度选择不当

随着用户量增长，需要开发了一个缓存系统来提高性能，这个系统需要允许多个线程同时读写不同的缓存项。

public class SimpleCache<K, V> {
    private Map<K, V> cache = new HashMap<>();
    
    public V get(K key) {
        synchronized(this) { // 对整个对象加锁
            return cache.get(key);
        }
    }
    
    public void put(K key, V value) {
        synchronized(this) { // 对整个对象加锁
            cache.put(key, value);
        }
    }
}

这段代码确实是线程安全的，但随着系统负载增加，你会发现性能开始急剧下降。用户开始抱怨系统响应缓慢，监控显示CPU利用率不高，但吞吐量却很低。

在代码中，我们对整个缓存对象加锁，导致即使线程操作的是不同的键值对，也必须排队等待，这就是所谓的"粗粒度锁"问题。

解决方案是使用更细粒度的锁设计，或者直接使用Java并发包中专门设计的并发集合：

public class ImprovedCache<K, V> {
    // 使用支持并发的集合
    private final ConcurrentHashMap<K, V> cache = new ConcurrentHashMap<>();
    
    public V get(K key) {
        return cache.get(key);
    }
    
    public void put(K key, V value) {
        cache.put(key, value);
    }
    
    // 对于需要原子性的复合操作
    public V putIfAbsent(K key, V value) {
        return cache.putIfAbsent(key, value);
    }
}

这样的改进就像是将超市改造成多个入口，顾客可以直接进入自己想去的区域。ConcurrentHashMap内部实现了分段锁机制，不同的键可能映射到不同的锁，大大提高了并发处理能力。

在实际项目中，这种优化可能会将系统的并发吞吐量提升数倍甚至数十倍。特别是在微服务架构中，一个看似小的锁优化可能会对整个系统的响应时间产生显著影响。在高并发环境中，细粒度锁往往是性能提升的关键。

三、多锁导致的死锁问题

在银行系统中，用户可以在不同账户之间转移资金。一个直观的实现可能是这样的：

public class BankAccount {
    private double balance;
    private final String accountId;
    
    public BankAccount(String accountId, double initialBalance) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
    
    public void transfer(BankAccount to, double amount) {
        synchronized(this) { // 先锁住当前账户
            if (balance >= amount) {
                synchronized(to) { // 再锁住目标账户
                    this.balance -= amount;
                    to.balance += amount;
                }
            }
        }
    }
}

这段代码看起来合理，先锁住源账户确认余额充足，再锁住目标账户完成转账。然而，在测试过程中，你可能会偶然发现系统有时会完全卡住，没有任何错误日志，应用程序也没有崩溃，但就是停止响应了。

这正是臭名昭著的死锁问题。

想象两个顾客A和B各自持有一把钥匙，且都需要两把钥匙才能完成操作。如果A拿着钥匙1等钥匙2，而B拿着钥匙2等钥匙1，他们将永远等待下去。在我们的代码中，当两个线程同时尝试在两个账户之间相互转账时：

线程1执行：accountA.transfer(accountB, 100)，锁住了accountA，等待accountB的锁
同时，线程2执行：accountB.transfer(accountA, 50)，锁住了accountB，等待accountA的锁

两个线程都无法继续执行，形成了死锁，系统陷入了永久等待状态。

解决这个问题需要一个巧妙的策略，让所有线程以相同的顺序获取锁：

public class SafeBankAccount {
    private double balance;
    private final String accountId;
    
    public SafeBankAccount(String accountId, double initialBalance) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
    
    public void transfer(SafeBankAccount to, double amount) {
        SafeBankAccount first = this;
        SafeBankAccount second = to;
        
        // 根据账户ID确定锁的获取顺序，防止死锁
        if (this.accountId.compareTo(to.accountId) > 0) {
            first = to;
            second = this;
        }
        
        synchronized(first) {
            synchronized(second) {
                if (this.balance >= amount) {
                    this.balance -= amount;
                    to.balance += amount;
                }
            }
        }
    }
}