尤其是在多年来不断增长的大型应用程序中，没有人能够全面了解应用程序中的技术流程、众多服务和调用链。但是，如果多个用户想要处理相同的数据，会发生什么情况？
内存漏洞和自建框架
你们每个人可能都熟悉的一个经典是内存漏洞 - 所谓的“内存泄漏”，它逐渐确保主内存被填满，直到不再起作用。然而，在框架成熟的时代，您可以更多地关注专业知识而不是技术，这种情况不再经常发生。
您还没有尝试过开发自己的 Spring 框架、编写内存缓存或在 EJB 中打开并行线程？那么一切都很好。
并发和锁定
应用程序服务器（在大多数情况下是数据库）控制和同步对共享资源（例如中央数据库中的数据记录）的所有并行访问。如果两个用户想要同时更改一个对象，第一个用户可以进行更改，而第二个用户必须等待。为此，将对所请求的资源进行锁定，以便一次只允许一个用户更改数据。事务结束时，一切都再次处于一致状态，并发布给所有其他用户——即 汽车邮件列表 所谓的 ACID 原则（原子性、一致性、隔离性和持久性）。
如果卡住了怎么办？
如果两个用户想要同时但以不同的顺序访问相同的对象，会发生什么情况？让我们看一个例子：用户 1 阻止“Julia”，用户 2 阻止“Klaus”，然后用户 1 也尝试阻止“Klaus” - 并且必须等待。与此同时，用户2也尝试阻止“Julia”，死锁完成。
通常数据库会检测到这里的死锁并引发相应的错误。但是，如果两个用户都执行长时间运行的事务，则第三步中可能已经发生延迟。
那么应该怎么办呢？
在这种情况下，您唯一的选择就是取消并回滚相关交易。然后，我们分析各种日志文件（包括数据库和应用程序），以便识别受影响的用例。
最终，软件开发人员必须开发应用程序并且：
1、统一锁请求的顺序。如果所有用例始终以相同的顺序请求锁（例如，根据主键按升序排列），那么从一开始就不会发生死锁。
2. 使用比悲观锁更乐观的锁定，因为这可以减少排他锁的持续时间。
3. 最大限度地缩短长期变更的持续时间，例如，在事务结束时将所有变更流程编写在一起，或者将用例拆分到多个事务中 - 如果可能的话。
4. 作为最后的手段，还应考虑重新设计应用程序，以便重组用例以及数据访问。
如果应用程序多年来不断增长，那么对象和服务的锁定和访问顺序很容易因多次扩展而变得混乱。那么是时候进行更广泛的重构了。
今天，所有问题都已解决，您的应用程序再次顺利无故障运行。
在我的下一篇博客文章中，我将研究检查数据库中的引用完整性可能产生的影响。