synchronized和lock锁(一)

本文深入探讨Java中synchronized关键字的使用,包括方法锁、对象锁和类锁的概念,以及如何通过ReentrantLock实现显式锁。通过具体代码示例,如SynchronizedEvenGenerator和MutexEvenGenerator,对比了synchronized与Lock接口在多线程环境下的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.声明synchronized方法的方式,这个称之为方法锁或者对象锁。

synchronized void f(){/*....*/}
synchronized void g(){/*....*/}

    所有的对象都自动含有单一的锁(也称为监视器,前面阅读Thread源码有提到监视器)。当在对象上调用任意synchronized方法时,此对象都被加锁,这时该对象上的其他synchronized方法只有等到前一个方法调用完毕释放了锁之后才能被调用。对于前面的方法,如果某个任务对对象调用了f(),对于同一个对象而言,只有等到f()调用结束并释放了锁之后,其他任务才能调用f()或者g()。所以,对于某个特定的对象来说,其所有的synchronized方法共享同一个锁,这可以被用来防止多个任务同时访问被编码对象内存。

    一个任务可以多次获得对象锁,也就是锁可重入。是指,一个方法在同一个对象上调用了第二个方法,后者又调用了同一个对象上的另外一个方法,就是发生锁的重入。JVM负责跟踪对象被枷锁的次数。如果一个对象被解锁也就说锁被完全释放,其计数变为0。在任务第一次给对象加锁时,计数变为1。每当这个相同的任务在这个对象上获得锁的时候,计数都会递增。显然,只有先获得了锁的任务才能允许继续获得锁。每当任务离开一个synchronized方法,计数递减,当计数为0的时候,锁被完全释放,此时别的任务就可以继续使用此资源。

2.类锁,可以看做特殊的对象锁,锁的是类对象

    针对每个类,也有一个锁,作为Class对象的一部分,所以synchronized static方法可以在类的范围内防止对static数据的并发访问。

3.显式使用Lock对象

    基本上,当你使用关键字synchronized关键字时,需要的代码量更少,并且用户出现错误的概率更低,因此通常只有解决特殊任务时才会使用到现实的Lock对象。比如,用synchronized不能尝试获取锁并且最终会获取锁失败,或者尝试着获取锁等待一段时间,这些需要concurrent类库

abstract class IntGenerator{
    private volatile boolean canceled = false;
    public abstract int next();
    public void cancel(){this.canceled =true;}
    public boolean isCanceled(){return this.canceled;}
}

class EvenChecker implements Runnable{

    private IntGenerator generator;
    private final int id;
    public EvenChecker(IntGenerator g,int ident){
        generator = g;
        id = ident;
    }

    public void run() {
        while (!generator.isCanceled()){
            int val = generator.next();
            if(val%2 != 0){
                System.out.println(val + " not even!");
                generator.cancel();
            }
        }
    }

    public static void test(IntGenerator gp,int count){
        System.out.println("Press Contrl-C to exit");
        ExecutorService exec = Executors.newCachedThreadPool();
        for(int i=0;i<count;i++){
            exec.execute(new EvenChecker(gp,i));
        }
        exec.shutdown();

    }

    public static void test(IntGenerator gp){
        test(gp,10);
    }
}

class SynchronizedEvenGenerator extends IntGenerator{
    private int currentVlaue = 0;

    public synchronized int next() {
        ++currentVlaue;
        //当不使用synchronized修饰next方法时,调用该方法可以促使线程同步调用异常发生
        //Thread.yield();
        //同样说明一个问题Thread。yield即便是让出cpu但是并没有释放锁
        ++currentVlaue;
        return currentVlaue;
    }
}

class MutexEvenGenerator extends IntGenerator{
    private int currentVlaue = 0;
    private Lock lock = new ReentrantLock();

    public int next() {
        lock.lock();
        try{
            ++currentVlaue;
            //当不使用synchronized修饰next方法时,调用该方法可以促使线程同步调用异常发生
            Thread.yield();
            //同样说明一个问题Thread。yield即便是让出cpu但是并没有释放锁
            ++currentVlaue;
            return currentVlaue;
        }finally {
            lock.unlock();
        }

    }
}

public class NesttyMain implements Serializable{

    public static void main(String[] args){
//        EvenChecker.test(new SynchronizedEvenGenerator());
        EvenChecker.test(new MutexEvenGenerator());
    }

}

 

转载于:https://my.oschina.net/u/1271447/blog/2998982

<think>嗯,用户要求我参考站内引用来介绍Java中synchronizedLock的区别及使用场景。用户在上次对话中已经详细询问过Java机制,这次聚焦在两种核心的对比上。 从引用内容看,用户提供的资料已经相当全面。引用[1][2][4][5]都直接对比了synchronizedLock的特性,尤其是引用[4]的对比表格非常清晰。我需要整合这些信息,同时结合自己掌握的Java并发知识来组织回答。 用户可能正在准备面试或设计并发程序,需要明确的决策依据。回答应该突出实际场景的选择建议,而不仅是理论差异。注意到引用[5]特别提到“synchronized适合低并发,ReentrantLock适合高并发”这个关键点,这应该是性能维度的核心结论。 在结构上,考虑先展示差异矩阵(参考引用[4]的表格形式),然后分别说明适用场景。对于使用示例,准备用代码片段展示两种的基本用法,特别是Lock必须配合try-finally释放这个易错点(引用[2][4]都强调过)。 用户可能还会关心升级机制(引用[2]提到synchronized的偏向优化)处理(引用[4]提到Lock可中断),这些都需要包含在回答中。最后考虑用流程图形式展示选择策略,帮助用户快速决策。</think>以下是Java中`synchronized`与`Lock`的详细对比及使用场景分析,结合核心引用内容整理: --- ### 、核心区别对比 | **特性** | **synchronized** | **Lock (ReentrantLock)** | |------------------------|------------------------------------------|-----------------------------------------| | **实现层级** | JVM层面关键字(内置) | Java API接口(`java.util.concurrent.locks`) | | **获取/释放** | 自动获取释放(代码块结束或异常时) | 必须手动调用`lock()``unlock()`[^4] | | **可中断性** | 等待中不可中断 | 支持`lockInterruptibly()`响应中断[^2][^5] | | **公平性** | 仅支持非公平 | 可通过构造参数指定公平/非公平[^2][^4] | | **状态检测** | 无法判断状态 | 可通过`tryLock()`检测是否被占用[^4][^5] | | **绑定条件** | 仅支持单等待队列 | 支持绑定多个`Condition`实现精准唤醒[^1][^3] | | **性能倾向** | 低竞争场景效率高(JVM自动优化升级)[^5] | 高竞争场景更优(减少线程挂起开销)[^1][^5] | | **粒度** | 方法级或代码块级 | 可灵活控制范围(如跨方法加)[^2] | --- ### 二、使用场景分析 #### 1. **优先选择 `synchronized` 的场景** - **简单同步需求**:如单方法内的临界区保护 ```java public synchronized void add() { count++; // 自动加/释放 } ``` - **低线程竞争环境**:JVM的升级(偏向→轻量级)可减少开销[^5] - **避免死风险**:自动释放机制降低编码失误概率[^4] #### 2. **优先选择 `Lock` 的场景** - **需要高级功能**: - 尝试获取(避免死): ```java if (lock.tryLock(1, TimeUnit.SECONDS)) { // 超时等待 try { /* 操作共享资源 */ } finally { lock.unlock(); } } ``` - 公平性要求:`new ReentrantLock(true)`[^4] - 多条件唤醒: ```java Condition condition = lock.newCondition(); condition.await(); // 精准唤醒特定线程 condition.signal(); ``` - **高并发写场景**:通过减少线程阻塞提升吞吐量[^5] - **跨方法控制**: ```java void methodA() { lock.lock(); try { ... } finally { /* 不在A方法释放 */ } } void methodB() { try { ... } finally { lock.unlock(); } // 在B方法释放 } ``` --- ### 三、底层原理差异 | **维度** | **synchronized** | **ReentrantLock** | |-------------------|--------------------------------------------------|-------------------------------------------| | **实现机制** | 对象头Mark Word + Monitor(JVM底层实现)[^2] | 基于AQS(AbstractQueuedSynchronizer)[^3] | | **升级路径** | 无 → 偏向 → 轻量级 → 重量级[^2] | 无升级概念 | | **重入实现** | 通过计数器递归实现[^3] | 同步状态state计数实现[^3] | > ⚠️ **注意**: > - `synchronized`在JDK6后引入升级,但**重量级不可逆**; > - `Lock`需严格在`finally`中释放,否则会导致死[^4][^5] --- ### 四、典型代码示例 #### 1. `ReentrantReadWriteLock` 读写分离(引用[4]) ```java ReadWriteLock rwLock = new ReentrantReadWriteLock(); // 读操作(共享) rwLock.readLock().lock(); try { // 多线程并发读 } finally { rwLock.readLock().unlock(); } // 写操作(独占) rwLock.writeLock().lock(); try { // 单线程写 } finally { rwLock.writeLock().unlock(); } ``` #### 2. `Lock` 响应中断(引用[5]) ```java Lock lock = new ReentrantLock(); try { lock.lockInterruptibly(); // 可被其他线程中断 try { /* 临界区 */ } finally { lock.unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 } ``` --- ### 五、选型决策流程图 ```mermaid graph TD A[需要同步?] --> B{竞争强度} B -->|低竞争| C[synchronized] B -->|高竞争| D{需高级功能?} D -->|是| E[ReentrantLock] D -->|否| C E --> F[需要读写分离?] F -->|是| G[ReentrantReadWriteLock] F -->|否| E ``` > 📌 **总结原则**: > 1. **简单优先**:无特殊需求时首选`synchronized` > 2. **灵活控制**:需超时、可中断、公平时用`Lock` > 3. **读写分离**:读多写少场景用`ReentrantReadWriteLock`[^4] --- ### 参考资料 [^1]: JavaLocksynchronized的全面对比 [^2]: SynchronizedLock的实现原理及使用场景 [^3]: synchronizedLock深度对比及高级用法 [^4]: synchronizedLock的区别使用示例 [^5]: synchronizedLock的面试题解析
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值