认识达内从这里开始

如何安排资源分配任务是多线程编程开发中需要重点关注的问题之一，而锁的应用会很好的解决这个问题，下面我们就通过案例分析来了解一下，并发编程开发中锁的概念与类型。

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的任务是没有感知的。

悲观锁每一次数据修改都要上锁，效率低，写数据失败的概率比较低，比较适合用在写多读少场景。

乐观锁并未真正加锁，效率高，写数据失败的概率比较高，容易发生业务形异常，比较适合用在读多写少场景。

是选择牺牲性能，还是追求效率，要根据业务场景判断，这种选择需要依赖经验判断，不过随着技术迭代，数据库的效率提升，集群模式的出现，性能和效率还是可以两全的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。