对于企业应用来说，齐全不波及到并发的问题，根本是不可能的。因为对于一个利用中很多的事件都是同时进行的。并发可能产生在数据获取，服务调用乃至于用户交互中。并发问题有两个重要的解决方案，一个是隔离，另一个是不变性。
并发问题会产生在多个执行单元同时拜访同一资源的时候，此时，一个好的办法就是分好“蛋糕”，让每一个执行单元都能拜访到各自的资源。好的并发设计就是：找到创立好隔离区的方法，而后通过剖析工作流让隔离区可能实现尽可能多的工作。
在共享数据能够扭转的状况下，并发问题就有可能产生。从理论的场景登程，同时有两个客户询问两位服务员是否还有某一货品时，两位服务员各自去查看了一下零碎并回复客户还有一份，两位客户中肯定有一位会悲观。那么这件事件的解决方案就是增加隔离区（购物车），服务员把以后货品放入客户的购物车胜利后告知用户，而后失败的一方就能够告知用户货品曾经销售一空。尽管存在已购用户退货的可能，但无疑比前一后果要好太多。这也就是下文中所说的乐观锁。
上面咱们开始介绍两种并发控制策略：
乐观和乐观并发管制
在某个零碎中，同时有两个企业员工 A 和 B 想要编辑同一个用户信息。此时 A 和 B 都获取到了用户的信息数据。而后他们两个进行了批改，A 员工先实现了操作并且进行了提交。而后 B 员工实现了操作也进行了提交。此时零碎中的这个用户信息只保留了 B 提供的数据，而抛弃了 A 员工的数据。这可能会造成一些难以预料的问题，甚至有可能导致他们丢掉工作。尽管能够通过操作日志来追溯到是哪个员工操作了数据，但这个信息没有任何意义，因为零碎并没有让任何员工得悉批改这一状况。
当一些可变数据无奈隔离时候，咱们能够用两种不同的控制策略：乐观锁策略和乐观锁策略。乐观锁用于冲突检测，乐观锁用于抵触防止。
悲观者策略非常简单，当 A 用户获取到用户信息时零碎把以后用户信息给锁定，而后 B 用户在获取用户信息时就会被告知他人正在编辑。等到 A 员工进行了提交，零碎才容许 B 员工获取数据。此时 B 获取的是 A 更新后的数据。
乐观者策略则不对获取进行任何限度，这时候咱们能够在用户信息中增加版本号来告知用户信息已被批改。乐观锁要求每条数据都有一个版本号，同时在更新数据时候就会更新版本号，如 A 员工在更新用户信息时候提交了以后的版本号。零碎判断 A 提交的时候的版本号和该条信息版本号统一，容许更新。而后零碎就会把版本号批改掉，B 员工来进行提交时携带的是之前版本号，此时零碎断定失败，要求 B 从新获取数据和版本号，而后再一次进行提交。
乐观锁和乐观锁进行抉择的规范是：抵触的频率和严重性。如果抵触的后果对于用户是难以承受的，咱们只能采纳乐观锁策略。如果抵触的后果不会很重大，或者频率也较低，咱们就能够抉择乐观锁，它更容易实现，也具备更好的并发性。
当然，咱们也能够对乐观锁进行一些优化，把更新工夫和更新用户增加到信息中，如此以来，零碎就能够告知 B 员工该条信息被批改过，以及在何时何人操作。零碎还能够提供给 B 新的更新工夫以及是否强制更新的抉择。当然，甚至能够基于业务需要以及日志信息等来告知 B 员工之前具体批改的信息。
死锁
应用乐观锁技术有一个特地的问题就是死锁，即用户在曾经获取锁的状况下还想要获取更多的锁。以最早的两个客户的问题来说，就是水果蛋糕须要获取水果和蛋糕，两个用户各有其中一种，并冀望获取对方货色。
解决死锁的办法是检测解决和超时管制。
查看解决会检测出死锁产生并且会抉择一个“牺牲者”，让他放弃他所领有的已保障另外一个客户能够获取水果蛋糕。而超时管制则是给每个锁增加一个超时工夫，一旦达到了超时工夫，以后的购物车外面的物品就被清掉。
超时管制和检测机制用于曾经产生了死锁的状况，而另外的办法则是防止死锁的产生。避免死锁的办法就是在用户获取锁的时候就获取所有可能须要的锁，粗力度锁（这很激进，但很无效），即水果蛋糕不是由两个货品组合而成的。
粗力度锁是笼罩多个资源的单个锁，这样会简化多个锁带来的复杂性。这其实也会产生在乐观锁的过程中，例如用户和用户相干地址信息，如果用户地址信息批改后也会更改用户信息，这样如何获取和设置乐观锁呢？咱们须要寻找到一组资源的外围。
同时，找到一组资源的外围也会使得开发的代码逻辑更加清晰。大家无妨想一下，在数据库层面的操作中，是抉择先更新子表而后再去更新主表这样的逻辑程序更好，还是以主表为入口进行更新批改更好呢？
激励一下
如果你感觉这篇文章不错，心愿能够给与我一些激励，在我的 github 博客下帮忙 star 一下。
博客地址