【多线程】锁机制详解

if(lock.tryLock()){//尝试获取锁
    try {
        // ... 获取锁后要做的内容
    } catch (Exception e) {
        throw new Exception(e);
    } finally {
        lock.unlock();
    }
}else{
    // 指定时间内没有获取到锁
}

● lockInterruptibly

lockInterruptibly 调用后，就会马上主动中断等待，并抛出 InterruptedException 异常

public class TestInterruptibly {

    static class Servier{
        private Lock lock = new ReentrantLock();        //定义锁对象
        public void serviceMethod(){
            try {
                lock.lockInterruptibly();   //如果线程被中断了,不会获得锁,会产生异常
                System.out.println(Thread.currentThread().getName() + "-- begin lock");
                //执行一段耗时的操作
                for (int i = 0; i < Integer.MAX_VALUE; i++) {
                    new StringBuilder();
                }
                System.out.println( Thread.currentThread().getName() + " -- end lock");
            } catch (InterruptedException e) {
//                e.printStackTrace();
                System.out.println( Thread.currentThread().getName() + " ***** exp");
            } finally {
                System.out.println( Thread.currentThread().getName() + " ***** 释放锁");
                lock.unlock();      //释放锁
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Servier  s = new Servier();
        Runnable r = new Runnable() {
            @Override
            public void run() {
                s.serviceMethod();
            }
        };
        Thread t1 = new Thread(r);
        t1.start();

        Thread.sleep(50);
        Thread t2 = new Thread(r);
        t2.start();
        Thread.sleep(50);
        t2.interrupt();     //中断t2线程
    }
}

三、悲观锁和乐观锁

3.1 悲观锁

悲观锁即每次去拿数据的时候都认为别人会修改，故每次拿数据的时候都会上锁。用处广泛，如数据库的行锁、表锁、读写锁等。

3.2 乐观锁

乐观锁即每次去拿数据的时候都认为别人不会修改，所以不会上锁。但在更新的时候回判断一下在此期间有没有人更新了这个数据，实现方式有版本号等方式。

3.3 适用场景

乐观锁适用于读多写少的情况，即冲突很少发生的时候，省去了锁的开销，增大了吞吐量

悲观锁适用于写多杜少的情况，在多写的情况下冲突经常发生，需要用锁来保证变量修改的有序性

3.4 实现方式

3.4.1 悲观锁实现

悲观锁常见的方式为 synchronized 和 lock

3.4.2 乐观锁实现

乐观锁需要在代码上进行设计和实现，一般有两种方式

● 版本控制

一般形式是在数据表上增加一个数据版本号字段(如 version)，用来表示数据修改的次数，当数据被修改时，version++。

在线程A要更新数据前，先读取一次数据，获取到对应的 version，在提交更新时，会将这个 version 放入查询条件中，只有当数据库中的 version 和提交更新的 version 一致时，才会更新，成功返回 1，失败返回 0。

举个例子：

有一个表 money，用于记录商户金额

修改 money 的 sql 语句为：

<update id="updateOne" parameterType="Money">
    update
        money
    set
        money=#{money},
        version=#{version}+1
    where id=#{id} and version=#{version}
</update>

更新方式：

@Service
public class MoneyServiceImpl implements MoneyService {

    @Autowired
    private MoneyMapper moneyMapper;

    @Override
    public void modifyMoney() {
        ExecutorService executor = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 100; i++) {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    int res = 0;
                    while (res == 0) {
                        try {
                            res = modify();
                            double rand = Math.random();
                            Thread.sleep((long) (500 + rand*100));
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }
                }
            });
        }
        try {
            System.in.read();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public int modify() {
        // 先获取到要更新的内容数据，包括金额和版本号
        Money money = moneyMapper.findById(1);
        // 修改金额
        money.setMoney(money.getMoney() + 1000);
        // 更新数据，sql 语句会保证找到对应版本号的数据，若没有一致的版本号则更新失败返回 0
        int res = moneyMapper.updateOne(money);
        // res = 0，更新失败
        if(res == 0) {
            // .. 更新失败的操作，如记录到失败表中，或是循环尝试个更新
            System.out.println("更新失败 tName = " + Thread.currentThread().getName() + " data = " + money.toString());
        } else {
            System.out.println("更新成功 tName = " + Thread.currentThread().getName() + " data = " + money.toString());
        }
        return res;
    }
}

● CAS 算法

CAS 全称(Compare And Swap 比较和交换)，是一种无锁算法，可以在不适用锁的情况下实现多线程间变量的同步java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁。

3.5 CAS 算法

3.5.1 概述

CAS 全称(Compare And Swap 比较和交换)，是一种无锁算法，可以在不适用锁的情况下实现多线程间变量的同步

3.5.2 运行机制

CAS 算法内部涉及到三个操作数：

需要读写的内存值V
旧值 A
要写入的新值 B

当且仅当 V 等于 A 时，CAS 通过原子方式(CAS的原子操作为：比较+更新) 使用新值 B 来更新 V的值，否则不会进行任何操作。同时会尝试不断更新，直到成功为止。

3.5.3 源码分析

由于 Java 的 AtomicInteger 是使用 CAS 算法实现乐观锁的，可以查看源码

/**
 * Atomically increments by one the current value.
 *
 * @return the previous value
 */
// 调用的自增算法，且能够保证并发下的线程安全
public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

unsafe：获取并操作内存的数据。
valueOffset：存储value在AtomicInteger中的偏移量。
value：要增长的数目，如每次加一

// ------------------------- OpenJDK 8 -------------------------
public final int getAndAddInt(Object o, long offset, int delta) {
   int v;
   do {
       v = getIntVolatile(o, offset);
   } while (!compareAndSwapInt(o, offset, v, v + delta));
   return v;
}

可以看到是通过不断循环 compareAndSwapInt() 实现的“比较 + 更新”操作。compareAndSwapInt 在 jni 中是借助于一个 cpu 指令完成的，是一个原子操作，可以保证线程安全性。当 compareAndSwapInt() 返回 true 时，则返回最新的变量给调用者，若返回 false, 则一直循环调用

3.5.4 存在的问题

● ABA 问题

通俗来讲就是你大爷还是你大爷，你大妈已经不是你大妈了

例如:

A => B => C

由于 CAS 算法是查看内存值是否发生变化，而进行更新的。如果原来的内存值是A，后面改成B，又改回了A，则 CAS 检查时就不会发现值变化了。

这会导致什么问题呢？

如果操作的对象是个链表，那么他里面的地址可能就全都被变化了

● 循环时间长，开销发

通俗来讲就是你大爷还是你大爷，你大妈已经不是你大妈了

例如:

A => B => C

四、其他名词

4.1 spinlock 自旋锁

4.1.1 概念

自旋锁即当锁被一个线程占用后，其他的线程不是阻塞挂起等待唤醒，而是不断循环尝试获取锁。

从自旋锁可以看出，其内部是使用了乐观锁的方式，避免了线程被挂起，同样可以使用 compareAndSwapInt() 实现

4.1.2 自旋锁的适用场景

● 适合场景 (锁占用时间短)

自旋锁适用于锁竞争不激烈，且占用锁时间非常短的代码块。由于自旋避免了线程的阻塞，且自旋的消耗远小于切换上下文的开销，能够极大提交这类代码块的性能

● 不适合的场景 (锁占用时间长)

自旋锁不适合用于锁竞争激烈，或是占用锁较长的代码块。

锁竞争激烈意味着更多的自旋锁开销，每个竞争者都在不断循环尝试获取锁。

而如果代码块占用锁时间较长，则会拖长自旋锁的循环判断时间，长时间占用 cpu，造成 cpu 的浪费

4.1.3 适应性自旋锁

● 概念

在 jdk1.6 中，引入了适应性自旋锁，适应性自旋锁即自旋的时间/次数不在固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。

● 机制

在同一个锁对象上，如果自旋等待刚刚成功获取过锁，且持有锁的线程正在运行中，虚拟机就会认为这次自旋也是很有可能再次成功，进而允许自旋锁持续更长时间。

如果对于某个锁，自旋很少成功获得过(长时间锁住或死锁)，虚拟机就会认为自旋尝试获取这个锁可能造成更大的开销，之后获取这个锁的时候没获取的线程都会被阻塞等待唤醒

● 实现类

TicketLock、CLHlock和MCSlock

4.2 无锁、偏向锁、轻量级锁、重量级锁

4.2.1 锁状态

根据锁的级别，从低到高依次是：无锁、偏向锁、轻量级锁和重量级锁

锁状态只能升级不能降级

4.2.1 重量级锁

重量级锁即多个线程竞争同步资源时，没有获取资源的线程会被阻塞等待唤醒。由于阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长，故 jdk6 后为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。