Java并发编程（十五）锁

此文为读书笔记，欢迎评论，谈论问题，共同进步！

---

乐观锁与悲观锁

乐观锁和悲观锁是在数据库中引入的名词，但是在并发包锁里面也引入了类似的思想。

悲观锁

悲观锁：指对数据被外界修改持悲观态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。
悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁（sql最后加上for update）。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。

下面我们用Spring的 JdbcTemplate 来简单演示一下悲观锁（只为演示，不做详细展示，用到表结构、实体类等等配置都很简单，此处不做详细阐述）：

数据库中有一条money为1000 的数据：

现在执行下下面的代码, 两个线程分别修改金额，最终金额是2000还是4000呢？

@SpringJUnitConfig(TxConfig.class)
public class LockTest {

    @Autowired
    private UserService userService;

    @Test
    public void pessimisticLock() throws InterruptedException {

        Thread threadA = new Thread(new Runnable() {
            @Override
            public void run() {
                User user = new User(new BigInteger("1"), "Jerry", "1", new BigDecimal("2000"));
                userService.updateByForUpdate(user);
            }
        });

        Thread threadB = new Thread(new Runnable() {
            @Override
            public void run() {
                // 上来先睡眠1s
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                User user = new User(new BigInteger("1"), "Jerry", "1", new BigDecimal("4000"));
                userService.update(user);
            }
        });

        threadA.start();
        threadB.start();

        threadA.join();
        threadB.join();
        System.out.println("main over!");

    }
}

@Override
@Transactional(propagation = Propagation.REQUIRED)
public int updateByForUpdate(User user) {
    userDao.getOneByForUpdate(new BigInteger("1"));
    user.setMoney(new BigDecimal("2000"));
    try {
        Thread.sleep(5000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return userDao.update(user);
}

@Override
public User getOneByForUpdate(BigInteger id) {
    String sql = "select * from user where id = ? for update";
    //调用方法
    return jdbcTemplate.queryForObject(sql, new BeanPropertyRowMapper<>(User.class), id);
}

@Override
public int update(User user) {
    return userDao.update(user);
}

@Override
public int update(User user) {
	String sql ="update user set name = ?, status = ?, money = ? where id = ?";
	Object[] args = {user.getName(), user.getStatus(), user.getMoney(), user.getId()};
	return jdbcTemplate.update(sql, args);
}

main over!

分析：

• threadA 修改Jerry的money字段为2000，修改之前获取排它锁，等执行完5s后释放排他锁；
• threadB 一上来就休眠1s，确保 threadA 占用排它锁，等threadA 执行完，threadB修改Jerry的money字段为4000；

看下数据库结果：

确实金额是4000，而不是2000

乐观锁

乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。具体来说，根据update返回的行数让用户决定如何去做。

下面我们做一下简单测试

比如Role表有一条数据（version 为 1）：

threadA 和 threadB 同时去更新上面的数据，都在当前版本version=1的基础上进行更新，如果更新个数为0，我们则主动抛个异常，请看下面代码：

@Test
public void optimisticLock() throws InterruptedException {

    Thread threadA = new Thread(new Runnable() {
        @Override
        public void run() {
            Role role = new Role("admin", "超级管理员", 1);
            int num = roleService.update(role);
            if (num == 0) {
                throw new RuntimeException("threadA 更新角色失败！");
            }
        }
    });

    Thread threadB = new Thread(new Runnable() {
        @Override
        public void run() {
            Role role = new Role("admin", "超级管理员Plus", 1);
            int num = roleService.update(role);
            if (num == 0) {
                throw new RuntimeException("threadB 更新角色失败！");
            }
        }
    });


    threadA.start();
    threadB.start();

    threadA.join();
    threadB.join();
    System.out.println("main over!");

}

@Override
public int update(Role role) {
    return roleDao.update(role);
}

@Override
    public int update(Role role) {
    String sql = "update role set role_name = ?, version = ? where role_code = ? and version = ?";
    Object[] args = {role.getRoleName(), role.getVersion()+1, role.getRoleCode(), role.getVersion()};
    return jdbcTemplate.update(sql, args);
}

Exception in thread "Thread-1" java.lang.RuntimeException: threadA 更新角色失败！
main over!
	at top.wushanghui.LockTest$3.run(LockTest.java:74)
	at java.lang.Thread.run(Thread.java:748)

看代码结果可知：threadB 更新成功，threadA更新失败。

数据库执行结果如下图：

到这里你是不是发现乐观锁是怎样的情况了吧！

乐观锁并不会使用数据库提供的锁机制，一般在表中添加 version字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。

公平锁与非公平锁

根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁，公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。而非公平锁则在运行时闯入，也就是先来不一定先得。

ReentrantLock 提供了公平和非公平锁的实现。

• 公平锁∶ReentrantLock pairLock = new ReentrantLock(true);
• 非公平锁∶ReentrantLock pairLock = new ReentrantLock(false);
  如果构造函数不传递参数，则默认是非公平锁。

例如：假设线程 A已经持有了锁，这时候线程B请求该锁其将会被挂起。当线程 A释放锁后，假如当前有线程C也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程 B和 线程C两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把 C挂起，让 B 获取当前锁。

在没有公平性需求的前提下尽量使用非公平锁，因为公平锁会带来性能开销。

独占锁与共享锁

根据锁只能被单个线程持有还是能被多个线程共同持有，锁可以分为独占锁和共享锁。

独占锁保证任何时候都只有一个线程能得到锁，ReentrantLock 就是以独占方式实现的。共享锁则可以同时由多个线程持有，例如 ReadWriteLock 读写锁，它允许一个资源可以被多线程同时进行读操作。
独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。
共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作。

可重入锁

当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞，那么当一个线程再次获取它自己已经获取的锁时是否会被阻塞呢？
如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数（严格来说是有限次数）地进入被该锁锁住的代码。

下面看一个例子，看看在什么情况下会使用可重入锁。

public class Hello {

	public s ynchr onized void helloA() {
		System.out.println("hello A");
	} 

	public synchronized void helloB() { 
		System.out.println("hello B");
		helloA() ;
	}
}

在如上代码中，调用helloB方法前会先获取内置锁，然后打印输出。之后调用 helloA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。

实际上，synchronized 内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为0，说明该锁没有被任何线程占用。当一个线程获取了该锁时，计数器的值会变成1，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。

但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为 null，这时候被阻塞的线程会被唤醒来竞争获取该锁。

自旋锁

由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其从内核状态切换到用户状态。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU 使用权的情况下，多次尝试获取（默认次数是10，可以使用 -XX:PreBlockSpinsh参数设置该值），很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用 CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了。