Java多线程下——各类锁的详解_java锁的类型有哪些-优快云博客

这里写目录标题

各类锁的详解

常见的锁策略

乐观锁 vs 悲观锁

悲观锁:

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

例： 同学 A 认为 "老师是比较忙的, 我来问问题, 老师不一定有空解答". 因此同学 A 会先给老师发消息: "老师你忙嘛? 我下午两点能来找你问个问题嘛?" (相当于加锁操作) 得到肯定的答复之后, 才会真的来问问题. 如果得到了否定的答复, 那就等一段时间, 下次再来和老师确定时间. 这个是悲观锁.

乐观锁：

假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并

发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

例： 同学 B 认为 "老师是比较闲的, 我来问问题, 老师大概率是有空解答的". 因此同学 B 直接就来找老师.(没加锁, 直接访问资源) 如果老师确实比较闲, 那么直接问题就解决了. 如果老师这会确实很忙, 那么同学 B 也不会打扰老师, 就下次再来(虽然没加锁, 但是能识别出数据访问冲突). 这个是乐观锁.

还记得我们之前经常提到的Synchronized吗？

Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略

首先说明一下我们熟知的Synchronized 不是读写锁.

Java 标准库提供ReentrantReadWriteLock 类, 实现了读写锁。

ReentrantReadWriteLock.ReadLock 类表示一个读锁. 这个对象提供了 lock / unlock 方法进行加锁解锁。

ReentrantReadWriteLock.WriteLock 类表示一个写锁. 这个对象也提供了 lock / unlock 方法进行加锁解锁。

读加锁和读加锁之间, 不互斥；

写加锁和写加锁之间, 互斥；

读加锁和写加锁之间, 互斥；

只要是涉及到 “互斥”, 就会产生线程的挂起等待. 一旦线程挂起, 再次被唤醒就不知道隔了多久了，因此尽可能减少 “互斥” 的机会, 就是提高效率的重要途径.

所以很明显了吧，读写锁更适合于 "频繁读, 不频繁写" 的场景中

重量级锁 vs 轻量级锁

synchronized 并不仅仅是对 mutex 进行封装, 在 synchronized 内部还做了很多其他的工作

嗯？不知道什么意思？那肯定不知道啊因为没说来着，下面我们来理解一下：

重量级锁: 加锁机制重度依赖了 OS 提供了 mutex

大量的内核态用户态切换
很容易引发线程的调度
这两个操作, 成本比较高. 一旦涉及到用户态和内核态的切换, 就意味着 "沧海桑田".

轻量级锁: 加锁机制尽可能不使用 mutex, 而是尽量在用户态代码完成. 实在搞不定了, 再使用 mutex.

少量的内核态用户态切换.
不太容易引发线程调度.

嗯。。。又来了我们熟悉的synchronized 开始是一个轻量级锁. 如果锁冲突比较严重, 就会变成重量级锁.

自旋锁（Spin Lock）

首先我们提出问题为什么是自旋锁，干啥的？

解：按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度.但实际上, 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU. 这个时候就可以使用自旋锁来处理这样的问题.

如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来.一旦锁被其他线程释放, 就能第一时间获取到锁.

自旋锁是一种典型的轻量级锁的实现方式.

优点: 没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁.
缺点: 如果锁被其他线程持有的时间比较久, 那么就会持续的消耗 CPU 资源. (而挂起等待的时候是不消耗 CPU 的)

公平锁 vs 非公平锁

公平锁: 遵守 “先来后到”. B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.
非公平锁: 不遵守 “先来后到”. B 和 C 都有可能获取到锁.

操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是非公平锁. 如果要想实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序.

synchronized 是非公平锁.

可重入锁 vs 不可重入锁

可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。

Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类，包括synchronized关键字锁都是可重入的。
Linux 系统提供的 mutex 是不可重入锁.

Compare and swap

CAS 是直接读写内存的, 而不是操作寄存器.

CAS 的读内存, 比较, 写内存操作是一条硬件指令, 是原子的.

CAS 有哪些应用:

实现原子类

标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现

典型的就是 AtomicInteger 类其中的 getAndIncrement ()相当于 i++ 操作.

通过形如上述代码就可以实现一个原子类. 不需要使用重量级锁, 就可以高效的完成多线程的自增操作.

本来 check and set 这样的操作在代码角度不是原子的. 但是在硬件层面上可以让一条指令完成这个操作, 也就变成原子的了.

实现自旋锁

基于 CAS 实现更灵活的锁, 获取到更多的控制权

CAS 的 ABA 问题

ABA问题描述：

假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A，接下来, 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要先读取 num 的值, 记录到 oldNum 变量中.使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z.但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A。
线程 t1 的 CAS 是期望 num 不变就修改. 但是 num 的值已经被 t2 给改了. 只不过又改成 A 了. 这个时候 t1 究竟是否要更新 num 的值为 Z 呢?

就像娶个新婚媳妇，怎么判断她在你之前是否有过无数个老公？

嗯？你说无所谓？都可以不介意？但是计算机不一样哦，来看一个Bug:

假设滑稽老哥有 100 存款. 滑稽想从 ATM 取 50 块钱. 取款机创建了两个线程并发的来执行 -50操作:

我们期望一个线程执行 -50 成功, 另一个线程 -50 失败.如果使用 CAS 的方式来完成这个扣款过程就可能出现问题.

正常的过程:

存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期
望更新为 50.
线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.
轮到线程2 执行了, 发现当前存款为 50, 和之前读到的 100 不相同, 执行失败.

异常的过程:

存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.

线程1 执行扣款成功, 存款被改成 50. 线程2 阻塞等待中.
在线程2 执行之前, 滑稽的朋友正好给滑稽转账 50, 账户余额变成 100 !!
轮到线程2 执行了, 发现当前存款为 100, 和之前读到的 100 相同, 再次执行扣款操作

你可以不介意媳妇，嗯。。理解理解但是钱。。。你不介意？

所以着急问我解决方案是什么了吧：

其实我们之前提到过就是引入版本号

CAS 操作在读取旧值的同时, 也要读取版本号.

真正修改的时候:

如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1.
如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了

在 Java 标准库中提供了 AtomicStampedReference<E> 类. 这个类可以对某个类进行包装, 在内部就提供了上面描述的版本管理功能.

Synchronized 原理

截止目前，本文前段我们已经了解了各种锁策略，期间也多次提到Synchronized，所以我们可以知道其具备以下特性：

开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁
开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.
实现轻量级锁的时候大概率用到的自旋锁策略
是一种不公平锁
是一种可重入锁
不是读写锁

JVM 将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级

没有听过偏向锁？

偏向锁不是真的 “加锁”, 只是给对象头中做一个 “偏向锁的标记”, 记录这个锁属于哪个线程
如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态

举个栗子理解偏向锁：

假设男主是一个锁, 女主是一个线程. 如果只有这一个线程来使用这个锁, 那么男主女主即使不领证结婚(避免了高成本操作), 也可以一直幸福的生活下去.但是,但是，但是，女配出现了, 也尝试竞争男主, 此时不管领证结婚这个操作成本多高, 女主也势必要把这个动作完成了, 让女配死心.

编译器+JVM 判断锁是否可消除. 如果可以, 就直接消除
有些应用程序的代码中, 用到了 synchronized, 但其实没有在多线程环境下. (例如 StringBuffer)

StringBuffer sb = new StringBuffer();
 sb.append("a");
 sb.append("b"); 
 sb.append("c");
 sb.append("d");

此时每个 append 的调用都会涉及加锁和解锁. 但如果只是在单线程中执行这个代码, 那么这些加锁解锁操作是没有必要的, 白白浪费了一些资源开销.

一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.

实际开发过程中, 使用细粒度锁, 是期望释放锁的时候其他线程能使用锁,但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会自动把锁粗化, 避免频繁申请释放锁.

举个栗子：

1、打开铅笔盒； 2、拿出橡皮； 3、关闭铅笔盒。

4、打开铅笔盒；5、拿出尺子； 6、关闭铅笔盒。

7、打开铅笔盒；8、拿出橡皮； 9、关闭铅笔盒。

然鹅。。人类会这样吗？当然不会，我们会：

1、打开铅笔盒； 2、拿出橡皮； 3、拿出尺子；4、拿出铅笔；5、关闭铅笔盒。

这就是Synchronized，不愧出自JVM对咱们Java程序猿够良心吧。。。

Callable 接口

Callable 是一个 interface . 相当于把线程封装了一个 "返回值". 方便程序猿借助多线程的方式计算结果.

我们举个栗子：

创建线程计算 1 + 2 + 3 + … + 1000

不使用 Callable 版本：

package demo2;

public class Test {
 
    static class Result {
 
        public int sum = 0;
        public Object lock = new Object();
    }

    public static void main(String[] args) throws InterruptedException {
 
        Result result = new Result();
        Thread t = new Thread() {
 
            @Override
            public void run() {
 
                int sum = 0;
                for (int i = 1; i <= 1000; i++) {
 
                    sum += i;
                }

                synchronized (result.lock) {
 
                    result.sum = sum;
                    result.lock.notify();
                }
            }
        };
        t.start();
        synchronized (result.lock) {
 
            while (result.sum == 0) {
 
                result.lock.wait();
            }
            System.out.println(result.sum);
        }
    }
}
可以看到, 上述代码需要一个辅助类 Result, 还需要使用一系列的加锁和 wait notify 操作, 代码复杂, 容易出错;所以我们看看使用 Callable 后。

使用 Callable 版本：

package demo2;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;

public class Test {
 
    public static void main(String[] args) throws ExecutionException, InterruptedException {
 
        Callable<Integer> callable = new Callable<Integer>() {
 
            @Override
            public Integer call() throws Exception {
 
                int sum = 0;
                for (int i = 1; i <= 1000; i++) {
 
                    sum += i;
                }
                return sum;
            }
        };
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        Thread t = new Thread(futureTask); t.start();
        int result = futureTask.get(); System.out.println(result);
    }
    
}

可以看到, 使用 Callable 和 FutureTask 之后, 代码简化了很多, 也不必手动写线程同步代码了.

Callable 和 Runnable 相对, 都是描述一个 "任务". Callable 描述的是带有返回值的任务, Runnable描述的是不带返回值的任务.

说明： Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为

Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.FutureTask 就可以负责这个等待结果出来的工作

ReentrantLock

JUC类下的可重入互斥锁. 和 synchronized 定位类似, 都是用来实现互斥效果, 保证线程安全

ReentrantLock 的用法:

lock(): 加锁, 如果获取不到锁就死等.
trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁.
unlock(): 解锁

ReentrantLock 和 synchronized 的区别:

synchronized 是一个关键字, 是 JVM 内部实现的(大概率是基于 C++ 实现).
ReentrantLock 是标准库的一个类, 在 JVM 外实现的(基于 Java 实现).
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更灵活, 但是也容易遗漏 unlock.
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.
synchronized 是非公平锁, ReentrantLock 默认是非公平锁. 可以通过构造方法传入一个 true 开启公平锁模式.
更强大的唤醒机制. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线程.

如何选择使用哪个锁?

锁竞争不激烈的时候, 使用 synchronized, 效率更高, 自动释放更方便.
锁竞争激烈的时候, 使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为, 而不是死等.
如果需要使用公平锁, 使用 ReentrantLock.

原子类内部用的是 CAS 实现，所以性能要比加锁实现 i++ 高很多。原子类有以下几个：

AtomicBoolean； AtomicInteger；AtomicIntegerArray；AtomicLong； AtomicReference； AtomicStampedReference

以 AtomicInteger 举例，常见方法有：

addAndGet(int delta); //i +=delta;

    decrementAndGet(); //--i;

    getAndDecrement(); //i--;

    incrementAndGet(); //++i;

    getAndIncrement(); //i++;

虽然创建销毁线程比创建销毁进程更轻量, 但是在频繁创建销毁线程的时候还是会比较低效所以线程池就是为了解决这个问题. 如果某个线程不再使用了, 并不是真正把线程释放, 而是放到一个 “池子” 中, 下次如果需要用到线程就直接从池子中取, 不必通过系统来创建了。

ExecutorService 和 Executors

ExecutorService 表示一个线程池实例.

Executors 是一个工厂类, 能够创建出几种不同风格的线程池.

ExecutorService 的 submit 方法能够向线程池中提交若干个任务.

Executors 创建线程池的几种方式

newFixedThreadPool: 创建固定线程数的线程池
newCachedThreadPool: 创建线程数目动态增长的线程池.
newSingleThreadExecutor: 创建只包含单个线程的线程池.
newScheduledThreadPool: 设定延迟时间后执行命令，或者定期执行命令. 是进阶版的 Timer.

Executors 本质上是 ThreadPoolExecutor 类的封装.

举个栗子：

package demo2;

import java.util.concurrent.*;

public class Test {
 
    public static void main(String[] args) {
 
        ExecutorService pool = Executors.newFixedThreadPool(10);
        pool.submit(new Runnable() {
 
            @Override
            public void run() {
 
                System.out.println("hello");
            }
        });
    }
}

ThreadPoolExecutor

理解 ThreadPoolExecutor 构造方法的参数:
把创建一个线程池想象成开个公司. 每个员工相当于一个线程.

corePoolSize: 正式员工的数量. (正式员工, 一旦录用, 永不辞退)maximumPoolSize: 正式员工 + 临时工的数目. (临时工: 一段时间不干活, 就被辞退).
keepAliveTime: 临时工允许的空闲时间.
unit: keepaliveTime 的时间单位, 是秒, 分钟, 还是其他值.
workQueue: 传递任务的阻塞队列
threadFactory: 创建线程的工厂, 参与具体的创建线程工作.
RejectedExecutionHandler: 拒绝策略, 如果任务量超出公司的负荷了接下来怎么处理.

AbortPolicy(): 超过负荷, 直接抛出异常.
CallerRunsPolicy(): 调用者负责处理
DiscardOldestPolicy(): 丢弃队列中最老的任务.
DiscardPolicy(): 丢弃新来的任务.

举个栗子：

package demo2;

import java.util.concurrent.*;

public class Test {
 
    public static void main(String[] args) {
 
        ExecutorService pool = new ThreadPoolExecutor(1, 2, 1000, TimeUnit.MILLISECONDS, new SynchronousQueue<Runnable>(), Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy());
        for (int i = 0; i < 3; i++) {
 
            pool.submit(new Runnable() {
 
                @Override
                public void run() {
 
                    System.out.println("hello");
                }
            });
        }
    }
}

线程池的工作流程

信号量 Semaphore

信号量, 用来表示 "可用资源的个数". 本质上就是一个计数器.
就象是停车场的展示牌: 当前有车位 100 个. 表示有 100 个可用资源.

当有车开进去的时候, 就相当于申请一个可用资源, 可用车位就 -1 (这个称为信号量的 P 操作)
当有车开出来的时候, 就相当于释放一个可用资源, 可用车位就 +1 (这个称为信号量的 V 操作)
如果计数器的值已经为 0 了, 还尝试申请资源, 就会阻塞等待, 直到有其他线程释放资源.

Semaphore 的 PV 操作中的加减计数器操作都是原子的, 可以在多线程环境下直接使用.

举个栗子：

创建 Semaphore 示例, 初始化为 4, 表示有 4 个可用资源.
acquire 方法表示申请资源(P操作), release 方法表示释放资源(V操作)
创建 20 个线程, 每个线程都尝试申请资源, sleep 1秒之后, 释放资源. 观察程序的执行效果

package demo2;

import java.util.concurrent.*;

public class Test {
 
    public static void main(String[] args) {
 
        Semaphore semaphore = new Semaphore(4);
        Runnable runnable = new Runnable() {
 
            @Override
            public void run() {
 
                try {
 
                    System.out.println("申请资源");
                    semaphore.acquire();
                    System.out.println("我获取到资源了");
                    Thread.sleep(1000);
                    System.out.println("我释放资源了");
                    semaphore.release();
                } catch (InterruptedException e) {
 
                    e.printStackTrace();
                }
            }
        };
        for (int i = 0; i < 20; i++) {
 
            Thread t = new Thread(runnable);
            t.start();
        }
    }
}

使用场景：

使用信号量可以实现 “共享锁”, 比如某个资源允许 3 个线程同时使用, 那么就可以使用 P 操作作为加锁, V 操作作为解锁, 前三个线程的 P 操作都能顺利返回, 后续线程再进行 P 操作就会阻塞等待,直到前面的线程执行了 V 操作.

多线程环境使用哈希表

Hashtable

只是简单的把关键方法加上了 synchronized 关键字

如果多线程访问同一个 Hashtable 就会直接造成锁冲突.
size 属性也是通过 synchronized 来控制同步, 也是比较慢的.
一旦触发扩容, 就由该线程完成整个扩容过程. 这个过程会涉及到大量的元素拷贝, 效率会非常低.

ConcurrentHashMap

相比于 Hashtable 做出了一系列的改进和优化

读操作没有加锁(但是使用了 volatile 保证从内存读取结果), 只对写操作进行加锁. 加锁的方式仍然是是用 synchronized, 但是不是锁整个对象, 而是 “锁桶” (用每个链表的头结点作为锁对象), 大大降低了锁冲突的概率.
充分利用 CAS 特性. 比如 size 属性通过 CAS 来更新. 避免出现重量级锁的情况.
优化了扩容方式: 化整为零

发现需要扩容的线程, 只需要创建一个新的数组, 同时只搬几个元素过去.
扩容期间, 新老数组同时存在.
后续每个来操作 ConcurrentHashMap 的线程, 都会参与搬家的过程. 每个操作负责搬运一小部分元素.
搬完最后一个元素再把老数组删掉.
这个期间, 插入只往新数组加.
这个期间, 查找需要同时查新数组和老数组

ConcurrentHashMap.每个哈希桶都有一把锁.只有两个线程访问的恰好是同一个哈希桶上的数据才出现锁冲突

死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

互斥：至少有一个资源必须处于非共享模式，即一次只有一个进程可使用。如果另一进程申请该资源，那么申请进程应等到该资源释放为止。
占有并等待：—个进程应占有至少一个资源，并等待另一个资源，而该资源为其他进程所占有。
非抢占：资源不能被抢占，即资源只能被进程在完成任务后自愿释放。
循环等待：有一组等待进程 {P0，P1，…，Pn}，P0 等待的资源为 P1 占有，P1 等待的资源为 P2 占有，……，Pn-1 等待的资源为 Pn 占有，Pn 等待的资源为 P0 占有。

举个栗子：

如何避免死锁

复习一下：

死锁产生的四个必要条件：

互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。

当上述四个条件都成立的时候，便形成死锁。当然，死锁的情况下如果打破上述任何一个条件，便可让死锁消失。

众所周知其中最容易破坏的就是 "循环等待".

破坏循环等待

最常用的一种死锁阻止技术就是锁排序. 假设有 N 个线程尝试获取 M 把锁, 就可以针对 M 把锁进行编号(1, 2, 3…M).

N 个线程尝试获取锁的时候, 都按照固定的按编号由小到大顺序来获取锁. 这样就可以避免环路等待.

可能环路等待示例：

package demo2;

import java.util.Hashtable;
import java.util.concurrent.*;

public class Test {
 
    public static void main(String[] args) {
 
        Object lock1 = new Object();
        Object lock2 = new Object();
        Thread t1 = new Thread() {
 
            @Override
            public void run() {
 
                synchronized (lock1) {
 
                    synchronized (lock2) {
 
                        // do something...
                    }
                }
            }
        };
        t1.start();
        Thread t2 = new Thread() {
 
            @Override
            public void run() {
 
                synchronized (lock2) {
 
                    synchronized (lock1) {
 
                        // do something...
                    }
                }
            }
        };
        t2.start();
    }
}

不会产生环路等待的代码:(对比一下)

约定好先获取 lock1, 再获取 lock2 , 就不会环路等待.

package demo2;

import java.util.Hashtable;
import java.util.concurrent.*;

public class Test {
 
    public static void main(String[] args) {
 
        Object lock1 = new Object();
        Object lock2 = new Object();
        Thread t1 = new Thread() {
 
            @Override
            public void run() {
 
                synchronized (lock1) {
 
                    synchronized (lock2) {
 
                        // do something...
                    }
                }
            }
        };
        t1.start();
        Thread t2 = new Thread() {
 
            @Override
            public void run() {
 
                synchronized (lock1) {
 
                    synchronized (lock2) {
 
                        // do something...
                    }
                }
            }
        };
        t2.start();
    }
}