一、资源和加锁
1、场景描述
多线程并发访问同一个资源问题，假如线程A获取变量之后修改变量值，线程C在此时也获取变量值并且修改，两个线程同时并发处理一个变量，就会导致并发问题。
这种并行处理数据库的情况在实际的业务开发中很常见，两个线程先后修改数据库的值，导致数据有问题，该问题复现的概率不大，处理的时候需要对整个模块体系有概念，才能容易定位问题。
2、演示案例
这里案例演示多线程并发修改count值，导致和预期不一致的结果，这是多线程并发下最常见的问题，尤其是在并发更新数据时。
出现并发的情况时，就需要通过一定的方式或策略来控制在并发情况下数据读写的准确性，这被称为并发控制，实现并发控制手段也很多，最常见的方式是资源加锁，还有一种简单的实现策略：修改数据前读取数据，修改的时候加入限制条件，保证修改的内容在此期间没有被修改。
二、锁的概念简介
1、锁机制简介
并发编程中一个最关键的问题，多线程并发处理同一个资源，防止资源使用的冲突一个关键解决方法，就是在资源上加锁：多线程序列化访问。锁是用来控制多个线程访问共享资源的方式，锁机制能够让共享资源在任意给定时刻只有一个线程任务访问，实现线程任务的同步互斥，这是最理想但性能最差的方式，共享读锁的机制允许多任务并发访问资源。
2、悲观锁
悲观锁，总是假设每次每次被读取的数据会被修改，所以要给读取的数据加锁，具有强烈的资源独占和排他特性，在整个数据处理过程中，将数据处于锁定状态，例如synchronized关键字的实现就是悲观机制。
悲观锁的实现，往往依靠数据库提供的锁机制，只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据，悲观锁主要分为共享读锁和排他写锁。
排他锁基本机制：又称写锁，允许获取排他锁的事务更新数据，阻止其他事务取得相同的资源的共享读锁和排他锁。若事务T对数据对象A加上写锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的写锁。
3、乐观锁
乐观锁相对悲观锁而言，采用更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务的开销非常的占资源，乐观锁机制在一定程度上解决了这个问题。
乐观锁大多是基于数据版本记录机制实现，为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个version字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制在高并发场景下，可能会导致大量更新失败的操作。
乐观锁的实现是策略层面的实现：CAS(Compare-And-Swap)。当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能成功更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
4、机制对比
悲观锁本身的实现机制就以损失性能为代价，多线程争抢，加锁、释放锁会导致比较多的上下文切换和调度延时，加锁的机制会产生额外的开销，还有增加产生死锁的概率，引发性能问题。
乐观锁虽然会基于对比检测的手段判断更新的数据是否有变化，但是不确定数据是否变化完成，例如线程1读取的数据是A1，但是线程2操作A1的值变化为A2，然后再次变化为A1，这样线程1的任务是没有感知的。
悲观锁每一次数据修改都要上锁，效率低，写数据失败的概率比较低，比较适合用在写多读少场景。
乐观锁并未真正加锁，效率高，写数据失败的概率比较高，容易发生业务形异常，比较适合用在读多写少场景。
是选择牺牲性能，还是追求效率，要根据业务场景判断，这种选择需要依赖经验判断，不过随着技术迭代，数据库的效率提升，集群模式的出现，性能和效率还是可以两全的。
三、Lock基础案例
1、Lock方法说明
lock：执行一次获取锁，获取后立即返回；
lockInterruptibly：在获取锁的过程中可以中断；
tryLock：尝试非阻塞获取锁，可以设置超时时间，如果获取成功返回true，有利于线程的状态监控；
unlock：释放锁，清理线程状态；
newCondition：获取等待通知组件，和当前锁绑定；
2、应用案例
这里多线程基于Lock锁机制，分别依次执行任务，这是Lock的基础用法，各种API的详解，下次再说。
3、与synchronized对比
基于synchronized实现的锁机制，安全性很高，但是一旦线程失败，直接抛出异常，没有清理线程状态的机会。显式的使用Lock语法，可以在finally语句中最终释放锁，维护相对正常的线程状态，在获取锁的过程中，可以尝试获取，或者尝试获取锁一段时间。
