DAO、Service、Controller分层,无状态/有状态bean,单例/多例,异步非阻塞/同步阻塞

496 2022-05-25 09:11

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

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

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

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

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

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

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

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

全部评论

·