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