一人一机，数据读写不会有问题、流程操作不会混乱。

但，往往，一系列骚操作是需要读取一系列数据，然后在这一系列数据不变的情况下，再去写一系列数据。

首先：简单环境1——就算只有一个人，也有可能在迭代的时候需要另存一份中间数据，而避免一开始的读入数据发生变化。那么就需要额外空间。因此，这额外空间属于自己的副本内部空间。

其次：简单环境2——多个人在互相配合却还是完成上面那一个人的工作的时候，这一个人的副本的中间数据可能就需要分享给其他人交接。于是中间态的数据有两种存放的可能，一是落地到简单环境1的数据库中，成为新的刻度数据；二是严格限定这些中间态的数据只能在这几个人之间交接，那也就是信息在这几个人传递中不落地。

综上：一项工程是有很多个人、很多部门流水线的操作完成。那么简单环境1与简单环境2就是各种排列组合。

于是：简而言之，还是数据读写的问题。然而数据读写除了1.副本操作不回传，如背景图片、场景描述。2.读取操作无后续依赖，较长保质期，比如轻易不动的配置，死亡烈士名单。之外。但凡自身改动会影响他人参考的。都会出现锁问题。而，为了产生原子效果。也就是原子操作不是1，而是多的时候，即事务操作需要回滚的，就需要一个函数来控制一个数据的读写，这个数据可能就是个结果状态。当然，还有的函数是为了解决纷争，保护的就是一套方法。这种全局一个的函数，就是单例模式。比如，您来了？什么？优先级不够，木婉清一巴掌上去，晕一会儿（自旋锁），醒啦？对不起啊，我刚跟一个老熟人打了声招呼，你在歇会儿吧你（去你的，又一巴掌）。哎呦，您终于醒了，怎么这么不小心，走路都摔晕啊，赶紧的吧，到您了，快去快去，我给你把门儿。

负责这种synchronized方法的类，我们称之为单例模式的执行人。全场能干出给人一嘴巴子事儿（原子操作的方法）的，有这么一个人就够了。比如连接数据库，JDBC辅助组件数据库连接的建立及保存、JDBC辅助组件增删改查的抽象操作。但是在dao操作之上的model（数据对象）却没必要单例，往往都是多例。而再往上，Service、Controller层属于控制对象，视角应放到控制流程上。他们使用单例模式，是为了减少对象的产生、垃圾回收、因为他们一个人能干很多类似的工作。就没必要请很多个演员摆排场讲面子了。前台，有一个美女就够了，没必要一对一的陪着客户聊天。service说对于我们这种稀缺的数据库资源，爱用不用、爱来不来，不来不伺候。controller说对于我们这种容器，请求就等着，不请求全能的上帝也不会多看你一眼。没错，前台美女就是计菜单的。传菜分发命令给每一个厨师的就是service。而service是无状态的。如果有，那么必然要单例保护。无状态就是谁都能用。谁喊一声都答应。有状态的就是同步阻塞，你叫我？你叫我你就不能走了，看着我干完再走，这叫同步，我只服务给你，期间我不会分神走私，这叫阻塞。你交代完就走，过会儿回来取，叫异步。我除了服务你，我还能嗑瓜子看电视剧，顺便再服务个别人，那就是我非阻塞。所以对于客户，是同步和异步的区别，对于服务提供者，是阻塞和非阻塞的区别。同一个操作，我服务器干不完就得等着，绝不干别的，就是阻塞了。而，有状态，就是要负责到底。有状态的bean就一定是阻塞的，因为肯定有人等着出结果呢。

所以，重要的并不是数据的读写，而是对于数据如何折腾然后记录一下结果。结果本身又是一堆新数据。而倒腾的过程才是真正要保护的原子操作。单例正是为这个而生的。但是单例模式下，全局变量和静态变量是不保证线程安全的。要想线程安全，需要用ThreadLocal空间换时间。

对非会员隐藏