引言
大家好，作为一名在校研二的Java开发者，我在参与大营销类用户增长系统的开发时，经常需要处理高并发场景下的数据一致性问题。在多线程环境下，如何保证共享资源的安全访问成为了我们必须面对的核心挑战。今天我想和大家深入聊聊Java中最基础也是最常用的同步机制——synchronized关键字。这篇文章不仅会讲解它的基本用法，还会结合我在实际项目中的经验，分享一些性能优化的小技巧，希望能帮助大家在实际开发中更好地使用这个强大的工具。
synchronized的基本概念与用法
什么是synchronized？
synchronized是Java提供的一个内置锁机制，用于实现线程同步，确保多个线程在访问共享资源时的互斥性。简单来说，它就像是一个房间的钥匙，一次只允许一个线程进入"房间"（临界区）执行代码。
synchronized的三种使用方式
在实际开发中，我们主要有三种方式来使用synchronized：
1. 同步实例方法
public class Counter { private int count = 0; // 同步实例方法：锁的是当前对象实例 public synchronized void increment() { count++; System.out.println("当前计数: " + count); } // 非同步方法，可以被多个线程同时访问 public void printCount() { System.out.println("计数器的值: " + count); } }代码说明：
synchronized修饰实例方法时，锁的是当前对象实例（this）- 同一时间只能有一个线程访问该对象的同步方法
- 不同对象的同步方法之间不会互斥
2. 同步静态方法
public class StaticCounter { private static int staticCount = 0; // 同步静态方法：锁的是类的Class对象 public static synchronized void staticIncrement() { staticCount++; System.out.println("静态计数: " + staticCount); } }代码说明：
synchronized修饰静态方法时，锁的是当前类的Class对象- 该锁对类的所有实例都有效
- 常用于保护静态共享资源
3. 同步代码块
public class FineGrainedLock { private final Object lock1 = new Object(); private final Object lock2 = new Object(); private int count1 = 0; private int count2 = 0; public void increment1() { // 同步代码块：使用指定的锁对象 synchronized(lock1) { count1++; System.out.println("count1: " + count1); } } public void increment2() { synchronized(lock2) { count2++; System.out.println("count2: " + count2); } } }代码说明：
- 可以指定任意对象作为锁
- 提供了更细粒度的锁控制
- 不同代码块可以使用不同的锁，提高并发性能
synchronized的实现原理
对象头与Monitor
要理解synchronized的工作原理，我们需要先了解Java对象的内存布局。每个Java对象在内存中都包含三部分：
| 组成部分 | 说明 | |---------|------| | 对象头 | 存储对象的元数据，包括Mark Word、类型指针等 | | 实例数据 | 对象的实际数据 | | 对齐填充 | 确保对象大小是8字节的倍数 |
其中，Mark Word是理解synchronized的关键。在32位JVM中，Mark Word的结构如下：
|-------------------------------------------------------| | 锁状态 | 25bit | 4bit | 1bit(偏向锁) | 2bit(锁标志) | |-------------------------------------------------------| | 无锁 | 对象的hashCode | 对象分代年龄 | 0 | 01 | | 偏向锁 | 线程ID | Epoch | 1 | 01 | | 轻量级锁 | 指向栈中锁记录的指针 | | 00 | | 重量级锁 | 指向互斥量(Monitor)的指针 | | 10 | | GC标记 | 空 | | | 11 |锁的升级过程
Java 6之后，synchronized实现了锁升级机制，这大大提高了性能：
- 无锁状态：初始状态，没有线程竞争
- 偏向锁：第一个线程访问时，会将线程ID记录在Mark Word中
- 轻量级锁：当有第二个线程尝试获取锁时，升级为轻量级锁（自旋锁）
- 重量级锁：自旋一定次数后仍无法获取锁，升级为重量级锁（互斥锁）
public class LockUpgradeDemo { private static int sharedValue = 0; public static void main(String[] args) throws InterruptedException { // 创建多个线程竞争同一个锁 Thread[] threads = new Thread[10]; for (int i = 0; i < threads.length; i++) { threads[i] = new Thread(() -> { // 这里会发生锁升级 synchronized(LockUpgradeDemo.class) { for (int j = 0; j < 1000; j++) { sharedValue++; } } }); } // 启动所有线程 for (Thread thread : threads) { thread.start(); } // 等待所有线程完成 for (Thread thread : threads) { thread.join(); } System.out.println("最终结果: " + sharedValue); } }实战中的优化技巧
1. 减小锁的粒度
在商城项目中，我遇到过这样一个场景：需要同步用户购物车操作，但不同用户的购物车之间其实不需要互斥。
优化前：
public class ShoppingCartService { // 锁的粒度过大，所有用户共享一个锁 private static final Object lock = new Object(); public void addToCart(String userId, Product product) { synchronized(lock) { // 添加商品到购物车 // 这里实际上只需要锁住当前用户的购物车 } } }优化后：
public class OptimizedShoppingCartService { // 使用ConcurrentHashMap存储用户锁 private final Map<String, Object> userLocks = new ConcurrentHashMap<>(); public void addToCart(String userId, Product product) { // 获取或创建用户专属的锁 Object userLock = userLocks.computeIfAbsent(userId, k -> new Object()); synchronized(userLock) { // 只锁住当前用户的购物车操作 // 不同用户的操作可以并行执行 } } }2. 使用读写锁替代完全同步
在营销抽奖系统中，我们经常需要读取配置信息，但很少修改。这种情况下，使用读写锁比synchronized更高效。
import java.util.concurrent.locks.ReentrantReadWriteLock; public class ConfigManager { private final Map<String, String> config = new HashMap<>(); private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); // 读操作：多个线程可以同时读取 public String getConfig(String key) { lock.readLock().lock(); try { return config.get(key); } finally { lock.readLock().unlock(); } } // 写操作：一次只允许一个线程写入 public void setConfig(String key, String value) { lock.writeLock().lock(); try { config.put(key, value); } finally { lock.writeLock().unlock(); } } }3. 避免死锁的实用技巧
死锁是多线程编程中的常见问题，这里分享几个我在项目中总结的避免死锁的方法：
public class DeadlockPrevention { // 方法1：按固定顺序获取锁 public void transfer(Account from, Account to, int amount) { // 通过比较账户ID确定锁的获取顺序 Account first = from.getId() < to.getId() ? from : to; Account second = from.getId() < to.getId() ? to : from; synchronized(first) { synchronized(second) { if (from.getBalance() >= amount) { from.withdraw(amount); to.deposit(amount); } } } } // 方法2：使用tryLock避免长时间等待 public boolean tryTransfer(Account from, Account to, int amount, long timeout, TimeUnit unit) throws InterruptedException { long stopTime = System.nanoTime() + unit.toNanos(timeout); while (true) { if (from.getLock().tryLock()) { try { if (to.getLock().tryLock()) { try { if (from.getBalance() >= amount) { from.withdraw(amount); to.deposit(amount); return true; } return false; } finally { to.getLock().unlock(); } } } finally { from.getLock().unlock(); } } if (System.nanoTime() > stopTime) { return false; } // 短暂休眠后重试 Thread.sleep(10); } } }synchronized的局限性及替代方案
虽然synchronized很强大，但在某些场景下也有局限性：
1. 无法中断等待锁的线程
public class InterruptibleLockExample { private final Object lock = new Object(); public void doWork() { synchronized(lock) { try { // 一旦进入同步块，就无法被中断 Thread.sleep(10000); } catch (InterruptedException e) { // 这里虽然捕获了中断，但线程仍然持有锁 Thread.currentThread().interrupt(); } } } }2. 使用ReentrantLock的解决方案
import java.util.concurrent.locks.ReentrantLock; public class BetterLockExample { private final ReentrantLock lock = new ReentrantLock(); public void doWork() { try { // 可以设置超时时间 if (lock.tryLock(1, TimeUnit.SECONDS)) { try { // 执行需要同步的代码 Thread.sleep(500); } finally { lock.unlock(); } } else { System.out.println("获取锁超时，执行其他逻辑"); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } public void interruptibleWork() throws InterruptedException { lock.lockInterruptibly(); // 可以响应中断的加锁方式 try { // 执行需要同步的代码 Thread.sleep(1000); } finally { lock.unlock(); } } }性能测试与对比
为了让大家更直观地了解不同同步方式的性能差异，我做了个简单的基准测试：
import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicInteger; public class SynchronizationBenchmark { private static final int THREAD_COUNT = 100; private static final int OPERATIONS_PER_THREAD = 10000; // 测试synchronized性能 static class SynchronizedCounter { private int count = 0; public synchronized void increment() { count++; } public int getCount() { return count; } } // 测试AtomicInteger性能 static class AtomicCounter { private AtomicInteger count = new AtomicInteger(0); public void increment() { count.incrementAndGet(); } public int getCount() { return count.get(); } } public static void main(String[] args) throws InterruptedException { System.out.println("开始性能测试..."); // 测试synchronized testSynchronized(); // 测试AtomicInteger testAtomic(); } private static void testSynchronized() throws InterruptedException { SynchronizedCounter counter = new SynchronizedCounter(); CountDownLatch latch = new CountDownLatch(THREAD_COUNT); long startTime = System.currentTimeMillis(); for (int i = 0; i < THREAD_COUNT; i++) { new Thread(() -> { for (int j = 0; j < OPERATIONS_PER_THREAD; j++) { counter.increment(); } latch.countDown(); }).start(); } latch.await(); long endTime = System.currentTimeMillis(); System.out.println("synchronized耗时: " + (endTime - startTime) + "ms"); System.out.println("最终计数: " + counter.getCount()); } private static void testAtomic() throws InterruptedException { AtomicCounter counter = new AtomicCounter(); CountDownLatch latch = new CountDownLatch(THREAD_COUNT); long startTime = System.currentTimeMillis(); for (int i = 0; i < THREAD_COUNT; i++) { new Thread(() -> { for (int j = 0; j < OPERATIONS_PER_THREAD; j++) { counter.increment(); } latch.countDown(); }).start(); } latch.await(); long endTime = System.currentTimeMillis(); System.out.println("AtomicInteger耗时: " + (endTime - startTime) + "ms"); System.out.println("最终计数: " + counter.getCount()); } }测试结果分析：
- 在低竞争情况下，AtomicInteger通常比synchronized更快
- 在高竞争情况下，synchronized的重量级锁模式可能更稳定
- 实际选择时需要根据具体场景权衡
总结
synchronized作为Java最基础的同步机制，虽然看起来简单，但背后有着复杂的优化逻辑。从偏向锁到轻量级锁再到重量级锁的升级过程，体现了JVM开发者在性能优化上的智慧。在实际开发中，我们需要根据具体场景选择合适的同步策略：对于简单的同步需求，synchronized足够好用；对于复杂的并发控制，可以考虑使用JUC包中的更高级工具。记住，没有最好的同步机制，只有最适合当前场景的解决方案。
