【原创】分布式之数据库和缓存双写一致性方案解析 【原创】分布式之消息队列复习精讲 【原创】分布式之延时任务方案解析 【原创】自己动手循序渐进实现观察者模式 【原创】自己动手实现牛逼的单例模式 【原创】自己动手实现牛逼的单例模式
【原创】分布式之数据库和缓存双写一致性方案解析
引言
为什么写这篇文章？
首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。
但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。目前没有一篇全面的博客，对这几种方案进行解析。于是博主战战兢兢，顶着被大家喷的风险，写了这篇文章。
文章结构
本文由以下三个部分组成
1、讲解缓存更新策略
2、对每种策略进行缺点分析
3、针对缺点给出改进方案
正文
先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。因此，接下来讨论的思路不依赖于给缓存设置过期时间这个方案。
在这里，我们讨论三种更新策略：
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
应该没人问我，为什么没有先更新缓存，再更新数据库这种策略。
(1)先更新数据库，再更新缓存
这套方案，大家是普遍反对的。为什么呢？有如下两点原因。
原因一（线程安全角度）
同时有请求A和请求B进行更新操作，那么会出现
（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
原因二（业务场景角度）
有如下两点：
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
接下来讨论的就是争议最大的，先删缓存，再更新数据库。还是先更新数据库，再删缓存的问题。
(2)先删缓存，再更新数据库
该方案会导致不一致的原因是。同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
那么，如何解决呢？采用延时双删策略
伪代码如下
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}转化为中文描述就是
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
这么做，可以将1秒内所造成的缓存脏数据，再次删除。
那么，这个1秒怎么确定的，具体该休眠多久呢？
针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
如果你用了mysql的读写分离架构怎么办？
ok，在这种情况下，造成数据不一致的原因如下，还是两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。
（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值
上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。
采用这种同步淘汰策略，吞吐量降低怎么办？
ok，那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。
第二次删除,如果删除失败怎么办？
这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库：
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
（6）请求A试图去删除请求B写入对缓存值，结果失败了。
ok,这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。
如何解决呢？
具体解决方案，且看博主对第(3)种更新策略的解析。
(3)先更新数据库，再删缓存
首先，先说一下。老外提出了一个缓存更新套路，名为《Cache-Aside pattern》。其中就指出
- 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存失效。
另外，知名社交网站facebook也在论文《Scaling Memcache at Facebook》中提出，他们用的也是先更新数据库，再删缓存的策略。
这种情况不存在并发问题么？
不是的。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
ok，如果发生上述情况，确实是会发生脏数据。
然而，发生这种情况的概率又有多少呢？
发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。
假设，有人非要抬杠，有强迫症，一定要解决怎么办？
如何解决上述并发问题？
首先，给缓存设有效时间是一种方案。其次，采用策略（2）里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。
还有其他造成不一致的原因么？
有的，这也是缓存更新策略（2）和缓存更新策略（3）都存在的一个问题，如果删缓存失败了怎么办，那不是会有不一致的情况出现么。比如一个写数据请求，然后写入数据库了，删缓存失败了，这会就出现不一致的情况了。这也是缓存更新策略（2）里留下的最后一个疑问。
如何解决？
提供一个保障的重试机制即可，这里给出两套方案。
方案一：
如下图所示
流程如下所示
（1）更新数据库数据；
（2）缓存因为种种问题删除失败
（3）将需要删除的key发送至消息队列
（4）自己消费消息，获得需要删除的key
（5）继续重试删除操作，直到成功
然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
方案二：
流程如下图所示：
（1）更新数据库数据
（2）数据库会将操作信息写入binlog日志当中
（3）订阅程序提取出所需要的数据以及key
（4）另起一段非业务代码，获得该信息
（5）尝试删除缓存操作，发现删除失败
（6）将这些信息发送至消息队列
（7）重新从消息队列中获得该数据，重试操作。
备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。至于oracle中，博主目前不知道有没有现成中间件可以使用。另外，重试机制，博主是采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。
总结
本文其实是对目前互联网中已有的一致性方案，进行了一个总结。对于先删缓存，再更新数据库的更新策略，还有方案提出维护一个内存队列的方式，博主看了一下，觉得实现异常复杂，没有必要，因此没有必要在文中给出。最后，希望大家有所收获。
参考文献
【原创】分布式之消息队列复习精讲
引言
为什么写这篇文章?
博主有两位朋友分别是小A和小B:
- 小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。
- 小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。
庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点
复习要点
本文大概围绕如下几点进行阐述:
- 为什么使用消息队列？
- 使用消息队列有什么缺点?
- 消息队列如何选型?
- 如何保证消息队列是高可用的？
- 如何保证消息不被重复消费?
- 如何保证消费的可靠性传输?
- 如何保证消息的顺序性？
我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大
正文
1、为什么要使用消息队列?
分析:一个用消息队列的人，不知道为啥用，这就有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。
回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰
(1)解耦
传统模式:
传统模式的缺点：
- 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
中间件模式:
中间件模式的的优点：
- 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
(2)异步
传统模式:
传统模式的缺点：
- 一些非必要的业务逻辑以同步的方式运行，太耗费时间。
中间件模式:
中间件模式的的优点：
- 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
(3)削峰
传统模式
传统模式的缺点：
- 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
中间件模式:
中间件模式的的优点：
- 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
2、使用了消息队列会有什么缺点?
分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！
回答:回答也很容易，从以下两个个角度来答
- 系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低
- 系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。
但是，我们该用还是要用的。
3、消息队列如何选型?
先说一下，博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka，对什么ZeroMQ等其他MQ没啥理解，因此只能基于这四种MQ给出回答。
分析:既然在项目中用了MQ，肯定事先要对业界流行的MQ进行调研，如果连每种MQ的优缺点都没了解清楚，就拍脑袋依据喜好，用了某种MQ，还是给项目挖坑。如果面试官问:"你为什么用这种MQ？。"你直接回答"领导决定的。"这种回答就很LOW了。还是那句话，不要给公司挖坑。
回答:首先，咱先上ActiveMQ的社区，看看该MQ的更新频率:
Apache ActiveMQ 5.15.3 Release
Christopher L. Shannon posted on Feb 12, 2018
Apache ActiveMQ 5.15.2 Released
Christopher L. Shannon posted on Oct 23, 2017
Apache ActiveMQ 5.15.0 Released
Christopher L. Shannon posted on Jul 06, 2017
省略以下记录
...我们可以看出，ActiveMq几个月才发一次版本，据说研究重心在他们的下一代产品Apollo。
接下来，我们再去RabbitMQ的社区去看一下,RabbitMQ的更新频率
RabbitMQ 3.7.3 release 30 January 2018
RabbitMQ 3.6.15 release 17 January 2018
RabbitMQ 3.7.2 release23 December 2017
RabbitMQ 3.7.1 release21 December 2017
省略以下记录
...我们可以看出，RabbitMQ版本发布比ActiveMq频繁很多。至于RocketMQ和kafka就不带大家看了，总之也比ActiveMQ活跃的多。详情，可自行查阅。
再来一个性能对比表
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 开发语言 | java | erlang | java | scala |
| 单机吞吐量 | 万级 | 万级 | 10万级 | 10万级 |
| 时效性 | ms级 | us级 | ms级 | ms级以内 |
| 可用性 | 高(主从架构) | 高(主从架构) | 非常高(分布式架构) | 非常高(分布式架构) |
| 功能特性 | 成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好 | 基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富 | MQ功能比较完备，扩展性佳 | 只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。 |
综合上面的材料得出以下两点:
(1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
(2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。具体该选哪个，看使用场景。
4、如何保证消息队列是高可用的？
分析:在第二点说过了，引入消息队列后，系统的可用性下降。在生产中，没人使用单机模式的消息队列。因此，作为一个合格的程序员，应该对消息队列的高可用有很深刻的了解。如果面试的时候，面试官问，你们的消息中间件如何保证高可用的？你的回答只是表明自己只会订阅和发布消息，面试官就会怀疑你是不是只是自己搭着玩，压根没在生产用过。请做一个爱思考，会思考，懂思考的程序员。
回答:这问题，其实要对消息队列的集群模式要有深刻了解，才好回答。
以rcoketMQ为例，他的集群就有多master 模式、多master多slave异步复制模式、多 master多slave同步双写模式。多master多slave模式部署架构图(网上找的,偷个懒，懒得画):
其实博主第一眼看到这个图，就觉得和kafka好像，只是NameServer集群，在kafka中是用zookeeper代替，都是用来保存和发现master和slave用的。通信过程如下:
Producer 与 NameServer集群中的其中一个节点（随机选择）建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker master，但是 Consumer 则不一样，它同时和提供 Topic 服务的 Master 和 Slave建立长连接，既可以从 Broker Master 订阅消息，也可以从 Broker Slave 订阅消息。
那么kafka呢,为了对比说明直接上kafka的拓补架构图(也是找的，懒得画)
如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。
至于rabbitMQ,也有普通集群和镜像集群模式，自行去了解，比较简单，两小时即懂。
要求，在回答高可用的问题时，应该能逻辑清晰的画出自己的MQ集群架构或清晰的叙述出来。
5、如何保证消息不被重复消费？
分析:这个问题其实换一种问法就是，如何保证消息队列的幂等性?这个问题可以认为是消息队列领域的基本问题。换句话来说，是在考察你的设计能力，这个问题的回答可以根据具体的业务场景来答，没有固定的答案。
回答:先来说一下为什么会造成重复消费?
其实无论是那种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说一下(如果还不懂，出门找一个kafka入门到精通教程),就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。
如何解决?这个问题针对业务场景来答分以下几点
(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。
6、如何保证消费的可靠性传输?
分析:我们在使用消息队列的过程中，应该做到消息不能多消费，也不能少消费。如果无法做到可靠性传输，可能给公司带来千万级别的财产损失。同样的，如果可靠性传输在使用过程中，没有考虑到，这不是给公司挖坑么，你可以拍拍屁股走了，公司损失的钱，谁承担。还是那句话，认真对待每一个项目，不要给公司挖坑。
回答:其实这个可靠性传输，每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
RabbitMQ
(1)生产者丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。
然而缺点就是吞吐量下降了。因此，按照博主的经验，生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。处理Ack和Nack的代码如下所示（说好不上代码的，偷偷上了）:
channel.addConfirmListener(new ConfirmListener() {
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
}); (2)消息队列丢数据
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步
1、将queue的持久化标识durable设置为true,则代表是一个持久的队列
2、发送消息的时候将deliveryMode=2
这样设置以后，rabbitMQ就算挂了，重启后也能恢复数据
(3)消费者丢数据
消费者丢数据一般是因为采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rahbitMQ会立即将消息删除，这种情况下如果消费者出现异常而没能处理该消息，就会丢失该消息。
至于解决方案，采用手动确认消息即可。
kafka
这里先引一张kafka Replication的数据流向图
Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader，然后无论该Topic的Replication Factor为多少（也即该Partition有多少个Replica），Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader中pull数据。
针对上述情况，得出如下分析
(1)生产者丢数据
在kafka生产中，基本都有一个leader和多个follwer。follwer会去同步leader的信息。因此，为了避免生产者丢数据，做如下两点配置
- 第一个配置要在producer端设置acks=all。这个配置保证了，follwer同步完成后，才认为消息发送成功。
- 在producer端设置retries=MAX，一旦写入失败，这无限重试
(2)消息队列丢数据
针对消息队列丢数据的情况，无外乎就是，数据还没同步，leader就挂了，这时zookpeer会将其他的follwer切换为leader,那数据就丢失了。针对这种情况，应该做两个配置。
- replication.factor参数，这个值必须大于1，即要求每个partition必须有至少2个副本
- min.insync.replicas参数，这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系
这两个配置加上上面生产者的配置联合起来用，基本可确保kafka不丢数据
(3)消费者丢数据
这种情况一般是自动提交了offset，然后你处理程序过程中挂了。kafka以为你处理好了。再强调一次offset是干嘛的
offset：指的是kafka的topic中的每个消费组消费的下标。简单的来说就是一条消息对应一个offset下标，每次消费数据的时候如果提交offset，那么下次消费就会从提交的offset加一那里开始消费。
比如一个topic中有100条数据，我消费了50条并且提交了，那么此时的kafka服务端记录提交的offset就是49(offset从0开始)，那么下次消费的时候offset就从50开始消费。
解决方案也很简单，改成手动提交即可。
ActiveMQ和RocketMQ
大家自行查阅吧
7、如何保证消息的顺序性？
分析:其实并非所有的公司都有这种业务需求，但是还是对这个问题要有所复习。
回答:针对这个问题，通过某种算法，将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。
有的人会问:那如果为了吞吐量，有多个消费者去消费怎么办？
这个问题，没有固定回答的套路。比如我们有一个微博的操作，发微博、写评论、删除微博，这三个异步操作。如果是这样一个业务场景，那只要重试就行。比如你一个消费者先执行了写评论的操作，但是这时候，微博都还没发，写评论一定是失败的，等一段时间。等另一个消费者，先执行写评论的操作后，再执行，就可以成功。
总之，针对这个问题，我的观点是保证入队有序就行，出队以后的顺序交给消费者自己去保证，没有固定套路。
总结
写到这里，希望读者把本文提出的这几个问题，经过深刻的准备后，一般来说，能囊括大部分的消息队列的知识点。如果面试官不问这几个问题怎么办，简单，自己把几个问题讲清楚，突出以下自己考虑的全面性。
最后，其实我不太提倡这样突击复习，希望大家打好基本功，做一个爱思考，懂思考，会思考的程序员。
【原创】分布式之延时任务方案解析
引言
在开发中，往往会遇到一些关于延时任务的需求。例如
- 生成订单30分钟未支付，则自动取消
- 生成订单60秒后,给用户发短信
对上述的任务，我们给一个专业的名字来形容，那就是延时任务。那么这里就会产生一个问题，这个延时任务和定时任务的区别究竟在哪里呢？一共有如下几点区别
- 定时任务有明确的触发时间，延时任务没有
- 定时任务有执行周期，而延时任务在某事件触发后一段时间内执行，没有执行周期
- 定时任务一般执行的是批处理操作是多个任务，而延时任务一般是单个任务
下面，我们以判断订单是否超时为例，进行方案分析
方案分析
(1)数据库轮询
思路
该方案通常是在小型项目中使用，即通过一个线程定时的去扫描数据库，通过订单时间来判断是否有超时的订单，然后进行update或delete等操作
实现
博主当年早期是用quartz来实现的(实习那会的事)，简单介绍一下
maven项目引入一个依赖如下所示
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.2.2</version>
</dependency>调用Demo类MyJob如下所示
package com.rjzheng.delay1;
import org.quartz.JobBuilder;
import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerException;
import org.quartz.SchedulerFactory;
import org.quartz.SimpleScheduleBuilder;
import org.quartz.Trigger;
import org.quartz.TriggerBuilder;
import org.quartz.impl.StdSchedulerFactory;
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
public class MyJob implements Job {
public void execute(JobExecutionContext context)
throws JobExecutionException {
System.out.println("要去数据库扫描啦。。。");
}
public static void main(String[] args) throws Exception {
// 创建任务
JobDetail jobDetail = JobBuilder.newJob(MyJob.class)
.withIdentity("job1", "group1").build();
// 创建触发器 每3秒钟执行一次
Trigger trigger = TriggerBuilder
.newTrigger()
.withIdentity("trigger1", "group3")
.withSchedule(
SimpleScheduleBuilder.simpleSchedule()
.withIntervalInSeconds(3).repeatForever())
.build();
Scheduler scheduler = new StdSchedulerFactory().getScheduler();
// 将任务及其触发器放入调度器
scheduler.scheduleJob(jobDetail, trigger);
// 调度器开始调度任务
scheduler.start();
}
}
运行代码，可发现每隔3秒，输出如下
要去数据库扫描啦。。。优缺点
优点:简单易行，支持集群操作
缺点:(1)对服务器内存消耗大
(2)存在延迟，比如你每隔3分钟扫描一次，那最坏的延迟时间就是3分钟
(3)假设你的订单有几千万条，每隔几分钟这样扫描一次，数据库损耗极大
(2)JDK的延迟队列
思路
该方案是利用JDK自带的DelayQueue来实现，这是一个无界阻塞队列，该队列只有在延迟期满的时候才能从中获取元素，放入DelayQueue中的对象，是必须实现Delayed接口的。
DelayedQueue实现工作流程如下图所示
其中Poll():获取并移除队列的超时元素，没有则返回空
take():获取并移除队列的超时元素，如果没有则wait当前线程，直到有元素满足超时条件，返回结果。
实现
定义一个类OrderDelay实现Delayed，代码如下
package com.rjzheng.delay2;
import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;
public class OrderDelay implements Delayed {
private String orderId;
private long timeout;
OrderDelay(String orderId, long timeout) {
this.orderId = orderId;
this.timeout = timeout + System.nanoTime();
}
public int compareTo(Delayed other) {
if (other == this)
return 0;
OrderDelay t = (OrderDelay) other;
long d = (getDelay(TimeUnit.NANOSECONDS) - t
.getDelay(TimeUnit.NANOSECONDS));
return (d == 0) ? 0 : ((d < 0) ? -1 : 1);
}
// 返回距离你自定义的超时时间还有多少
public long getDelay(TimeUnit unit) {
return unit.convert(timeout - System.nanoTime(), TimeUnit.NANOSECONDS);
}
void print() {
System.out.println(orderId+"编号的订单要删除啦。。。。");
}
}运行的测试Demo为，我们设定延迟时间为3秒
package com.rjzheng.delay2;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.DelayQueue;
import java.util.concurrent.TimeUnit;
public class DelayQueueDemo {
public static void main(String[] args) {
// TODO Auto-generated method stub
List<String> list = new ArrayList<String>();
list.add("00000001");
list.add("00000002");
list.add("00000003");
list.add("00000004");
list.add("00000005");
DelayQueue<OrderDelay> queue = new DelayQueue<OrderDelay>();
long start = System.currentTimeMillis();
for(int i = 0;i<5;i++){
//延迟三秒取出
queue.put(new OrderDelay(list.get(i),
TimeUnit.NANOSECONDS.convert(3, TimeUnit.SECONDS)));
try {
queue.take().print();
System.out.println("After " +
(System.currentTimeMillis()-start) + " MilliSeconds");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}输出如下
00000001编号的订单要删除啦。。。。
After 3003 MilliSeconds
00000002编号的订单要删除啦。。。。
After 6006 MilliSeconds
00000003编号的订单要删除啦。。。。
After 9006 MilliSeconds
00000004编号的订单要删除啦。。。。
After 12008 MilliSeconds
00000005编号的订单要删除啦。。。。
After 15009 MilliSeconds可以看到都是延迟3秒，订单被删除
优缺点
优点:效率高,任务触发时间延迟低。
缺点:(1)服务器重启后，数据全部消失，怕宕机
(2)集群扩展相当麻烦
(3)因为内存条件限制的原因，比如下单未付款的订单数太多，那么很容易就出现OOM异常
(4)代码复杂度较高
(3)时间轮算法
思路
先上一张时间轮的图(这图到处都是啦)
时间轮算法可以类比于时钟，如上图箭头（指针）按某一个方向按固定频率轮动，每一次跳动称为一个 tick。这样可以看出定时轮由个3个重要的属性参数，ticksPerWheel（一轮的tick数），tickDuration（一个tick的持续时间）以及 timeUnit（时间单位），例如当ticksPerWheel=60，tickDuration=1，timeUnit=秒，这就和现实中的始终的秒针走动完全类似了。
如果当前指针指在1上面，我有一个任务需要4秒以后执行，那么这个执行的线程回调或者消息将会被放在5上。那如果需要在20秒之后执行怎么办，由于这个环形结构槽数只到8，如果要20秒，指针需要多转2圈。位置是在2圈之后的5上面（20 % 8 + 1）
实现
我们用Netty的HashedWheelTimer来实现
给Pom加上下面的依赖
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.24.Final</version>
</dependency>测试代码HashedWheelTimerTest如下所示
package com.rjzheng.delay3;
import io.netty.util.HashedWheelTimer;
import io.netty.util.Timeout;
import io.netty.util.Timer;
import io.netty.util.TimerTask;
import java.util.concurrent.TimeUnit;
public class HashedWheelTimerTest {
static class MyTimerTask implements TimerTask{
boolean flag;
public MyTimerTask(boolean flag){
this.flag = flag;
}
public void run(Timeout timeout) throws Exception {
// TODO Auto-generated method stub
System.out.println("要去数据库删除订单了。。。。");
this.flag =false;
}
}
public static void main(String[] argv) {
MyTimerTask timerTask = new MyTimerTask(true);
Timer timer = new HashedWheelTimer();
timer.newTimeout(timerTask, 5, TimeUnit.SECONDS);
int i = 1;
while(timerTask.flag){
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(i+"秒过去了");
i++;
}
}
}输出如下
1秒过去了
2秒过去了
3秒过去了
4秒过去了
5秒过去了
要去数据库删除订单了。。。。
6秒过去了优缺点
优点:效率高,任务触发时间延迟时间比delayQueue低，代码复杂度比delayQueue低。
缺点:(1)服务器重启后，数据全部消失，怕宕机
(2)集群扩展相当麻烦
(3)因为内存条件限制的原因，比如下单未付款的订单数太多，那么很容易就出现OOM异常
(4)redis缓存
思路一
利用redis的zset,zset是一个有序集合，每一个元素(member)都关联了一个score,通过score排序来取集合中的值
zset常用命令
添加元素:ZADD key score member [[score member] [score member] ...]
按顺序查询元素:ZRANGE key start stop [WITHSCORES]
查询元素score:ZSCORE key member
移除元素:ZREM key member [member ...]
测试如下
# 添加单个元素
redis> ZADD page_rank 10 google.com
(integer) 1
# 添加多个元素
redis> ZADD page_rank 9 baidu.com 8 bing.com
(integer) 2
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"
5) "google.com"
6) "10"
# 查询元素的score值
redis> ZSCORE page_rank bing.com
"8"
# 移除单个元素
redis> ZREM page_rank google.com
(integer) 1
redis> ZRANGE page_rank 0 -1 WITHSCORES
1) "bing.com"
2) "8"
3) "baidu.com"
4) "9"那么如何实现呢？我们将订单超时时间戳与订单号分别设置为score和member,系统扫描第一个元素判断是否超时，具体如下图所示
实现一
package com.rjzheng.delay4;
import java.util.Calendar;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Tuple;
public class AppTest {
private static final String ADDR = "127.0.0.1";
private static final int PORT = 6379;
private static JedisPool jedisPool = new JedisPool(ADDR, PORT);
public static Jedis getJedis() {
return jedisPool.getResource();
}
//生产者,生成5个订单放进去
public void productionDelayMessage(){
for(int i=0;i<5;i++){
//延迟3秒
Calendar cal1 = Calendar.getInstance();
cal1.add(Calendar.SECOND, 3);
int second3later = (int) (cal1.getTimeInMillis() / 1000);
AppTest.getJedis().zadd("OrderId", second3later,"OID0000001"+i);
System.out.println(System.currentTimeMillis()+"ms:redis生成了一个订单任务：订单ID为"+"OID0000001"+i);
}
}
//消费者，取订单
public void consumerDelayMessage(){
Jedis jedis = AppTest.getJedis();
while(true){
Set<Tuple> items = jedis.zrangeWithScores("OrderId", 0, 1);
if(items == null || items.isEmpty()){
System.out.println("当前没有等待的任务");
try {
Thread.sleep(500);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
continue;
}
int score = (int) ((Tuple)items.toArray()[0]).getScore();
Calendar cal = Calendar.getInstance();
int nowSecond = (int) (cal.getTimeInMillis() / 1000);
if(nowSecond >= score){
String orderId = ((Tuple)items.toArray()[0]).getElement();
jedis.zrem("OrderId", orderId);
System.out.println(System.currentTimeMillis() +"ms:redis消费了一个任务：消费的订单OrderId为"+orderId);
}
}
}
public static void main(String[] args) {
AppTest appTest =new AppTest();
appTest.productionDelayMessage();
appTest.consumerDelayMessage();
}
}此时对应输出如下
1525086085261ms:redis生成了一个订单任务：订单ID为OID00000010
1525086085263ms:redis生成了一个订单任务：订单ID为OID00000011
1525086085266ms:redis生成了一个订单任务：订单ID为OID00000012
1525086085268ms:redis生成了一个订单任务：订单ID为OID00000013
1525086085270ms:redis生成了一个订单任务：订单ID为OID00000014
1525086088000ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525086088001ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525086088002ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525086088003ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525086088004ms:redis消费了一个任务：消费的订单OrderId为OID00000014
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务可以看到，几乎都是3秒之后，消费订单。
然而，这一版存在一个致命的硬伤，在高并发条件下，多消费者会取到同一个订单号，我们上测试代码ThreadTest
package com.rjzheng.delay4;
import java.util.concurrent.CountDownLatch;
public class ThreadTest {
private static final int threadNum = 10;
private static CountDownLatch cdl = new CountDownLatch(threadNum);
static class DelayMessage implements Runnable{
public void run() {
try {
cdl.await();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
AppTest appTest =new AppTest();
appTest.consumerDelayMessage();
}
}
public static void main(String[] args) {
AppTest appTest =new AppTest();
appTest.productionDelayMessage();
for(int i=0;i<threadNum;i++){
new Thread(new DelayMessage()).start();
cdl.countDown();
}
}
}
输出如下所示
1525087157727ms:redis生成了一个订单任务：订单ID为OID00000010
1525087157734ms:redis生成了一个订单任务：订单ID为OID00000011
1525087157738ms:redis生成了一个订单任务：订单ID为OID00000012
1525087157747ms:redis生成了一个订单任务：订单ID为OID00000013
1525087157753ms:redis生成了一个订单任务：订单ID为OID00000014
1525087160009ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160011ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160012ms:redis消费了一个任务：消费的订单OrderId为OID00000010
1525087160022ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160023ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160029ms:redis消费了一个任务：消费的订单OrderId为OID00000011
1525087160038ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160045ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160048ms:redis消费了一个任务：消费的订单OrderId为OID00000012
1525087160053ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525087160064ms:redis消费了一个任务：消费的订单OrderId为OID00000013
1525087160065ms:redis消费了一个任务：消费的订单OrderId为OID00000014
1525087160069ms:redis消费了一个任务：消费的订单OrderId为OID00000014
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务
当前没有等待的任务显然，出现了多个线程消费同一个资源的情况。
解决方案
(1)用分布式锁，但是用分布式锁，性能下降了，该方案不细说。
(2)对ZREM的返回值进行判断，只有大于0的时候，才消费数据，于是将consumerDelayMessage()方法里的
if(nowSecond >= score){
String orderId = ((Tuple)items.toArray()[0]).getElement();
jedis.zrem("OrderId", orderId);
System.out.println(System.currentTimeMillis()+"ms:redis消费了一个任务：消费的订单OrderId为"+orderId);
}修改为
if(nowSecond >= score){
String orderId = ((Tuple)items.toArray()[0]).getElement();
Long num = jedis.zrem("OrderId", orderId);
if( num != null && num>0){
System.out.println(System.currentTimeMillis()+"ms:redis消费了一个任务：消费的订单OrderId为"+orderId);
}
}在这种修改后，重新运行ThreadTest类，发现输出正常了
思路二
该方案使用redis的Keyspace Notifications，中文翻译就是键空间机制，就是利用该机制可以在key失效之后，提供一个回调，实际上是redis会给客户端发送一个消息。是需要redis版本2.8以上。
实现二
在redis.conf中，加入一条配置
notify-keyspace-events Ex运行代码如下
package com.rjzheng.delay5;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPubSub;
public class RedisTest {
private static final String ADDR = "127.0.0.1";
private static final int PORT = 6379;
private static JedisPool jedis = new JedisPool(ADDR, PORT);
private static RedisSub sub = new RedisSub();
public static void init() {
new Thread(new Runnable() {
public void run() {
jedis.getResource().subscribe(sub, "__keyevent@0__:expired");
}
}).start();
}
public static void main(String[] args) throws InterruptedException {
init();
for(int i =0;i<10;i++){
String orderId = "OID000000"+i;
jedis.getResource().setex(orderId, 3, orderId);
System.out.println(System.currentTimeMillis()+"ms:"+orderId+"订单生成");
}
}
static class RedisSub extends JedisPubSub {
@Override
public void onMessage(String channel, String message) {
System.out.println(System.currentTimeMillis()+"ms:"+message+"订单取消");
}
}
}
输出如下
1525096202813ms:OID0000000订单生成
1525096202818ms:OID0000001订单生成
1525096202824ms:OID0000002订单生成
1525096202826ms:OID0000003订单生成
1525096202830ms:OID0000004订单生成
1525096202834ms:OID0000005订单生成
1525096202839ms:OID0000006订单生成
1525096205819ms:OID0000000订单取消
1525096205920ms:OID0000005订单取消
1525096205920ms:OID0000004订单取消
1525096205920ms:OID0000001订单取消
1525096205920ms:OID0000003订单取消
1525096205920ms:OID0000006订单取消
1525096205920ms:OID0000002订单取消可以明显看到3秒过后，订单取消了
ps:redis的pub/sub机制存在一个硬伤，官网内容如下
原:Because Redis Pub/Sub is fire and forget currently there is no way to use this feature if your application demands reliable notification of events, that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost.
翻: Redis的发布/订阅目前是即发即弃(fire and forget)模式的，因此无法实现事件的可靠通知。也就是说，如果发布/订阅的客户端断链之后又重连，则在客户端断链期间的所有事件都丢失了。
因此，方案二不是太推荐。当然，如果你对可靠性要求不高，可以使用。
优缺点
优点:(1)由于使用Redis作为消息通道，消息都存储在Redis中。如果发送程序或者任务处理程序挂了，重启之后，还有重新处理数据的可能性。
(2)做集群扩展相当方便
(3)时间准确度高
缺点:(1)需要额外进行redis维护
(5)使用消息队列
我们可以采用rabbitMQ的延时队列。RabbitMQ具有以下两个特性，可以实现延迟队列
- RabbitMQ可以针对Queue和Message设置 x-message-tt，来控制消息的生存时间，如果超时，则消息变为dead letter
- lRabbitMQ的Queue可以配置x-dead-letter-exchange 和x-dead-letter-routing-key（可选）两个参数，用来控制队列内出现了deadletter，则按照这两个参数重新路由。
结合以上两个特性，就可以模拟出延迟消息的功能,具体的，我改天再写一篇文章，这里再讲下去，篇幅太长。
优缺点
优点: 高效,可以利用rabbitmq的分布式特性轻易的进行横向扩展,消息支持持久化增加了可靠性。
缺点：本身的易用度要依赖于rabbitMq的运维.因为要引用rabbitMq,所以复杂度和成本变高
总结
本文总结了目前互联网中，绝大部分的延时任务的实现方案。希望大家在工作中能够有所收获。
其实大家在工作中，百分九十的人还是以业务逻辑为主，很少有机会能够进行方案设计。所以博主不推荐在分布式这块，花太多时间，应该看看《手把手系列的文章》。不过，鉴于现在的面试造火箭，工作拧螺丝现象太过严重，所以博主开始写《分布式系列》，最后来个小漫画娱乐一下。
【原创】自己动手循序渐进实现观察者模式
引言
自上一篇《自己动手实现牛逼的单例模式》问世之后，得到了不错的评价。于是博主在五一放弃出去游玩机会，赶制了这篇《自己动手循序渐进实现观察者模式》，依然还是一步一步推导出最终版的观察者模式。
观察者模式
定义：在许多设计中，经常涉及多个对象都对一个特殊对象中的数据变化感兴趣，而且这多个对象都希望跟踪那个特殊对象中的数据变化，在这样的情况下就可以使用观察者模式。
在这里，我们以母亲观察宝宝为例子，宝宝正在睡觉，醒来后，母亲做出相应的喂食行为。
1、观察者V1
假设我们用下图所示的情景
先定义一个Baby类，baby先睡五秒，五秒后醒来，代码如下所示
package rjzheng.observer1;
public class Baby implements Runnable {
// 默认是睡着
private boolean wakeup = false;
// 醒来的行为
public void wakeUp() {
this.wakeup = true;
}
public boolean isWakeup() {
return wakeup;
}
public void setWakeup(boolean wakeup) {
this.wakeup = wakeup;
}
@Override
public void run() {
// TODO Auto-generated method stub
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
wakeUp();
}
}而母亲类即Mother类，则一直监听宝宝的状态，宝宝一醒来就喂食，代码如下所示
package rjzheng.observer1;
public class Mother implements Runnable {
private Baby baby;
public Mother(Baby baby) {
this.baby = baby;
}
public void feed(Baby baby){
System.out.println("已经给宝贝喂食");
}
@Override
public void run(){
while(!baby.isWakeup()){
for(int i=0;i<5;i++){
try {
Thread.sleep(1000);
System.out.println("宝宝还有"+(5-i)+"秒醒来");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
this.feed(baby);
}
}
然后写一个ObserverTest1测试一下，代码如下所示
package rjzheng.observer1;
public class ObserverTest1 {
public static void main(String[] args) {
Baby baby =new Baby();
new Thread(baby).start();
new Thread(new Mother(baby)).start();
}
}输出如下
宝宝还有5秒醒来
宝宝还有4秒醒来
宝宝还有3秒醒来
宝宝还有2秒醒来
宝宝还有1秒醒来
已经给宝贝喂食2、观察者V2
这时情景变为下图
可是上一版，母亲要一直看着宝宝，母亲觉得太累了，母亲要是想中间聊个微信啥的，多不方便，于是V2版出现了。我们能不能孩子醒来后，主动告诉给母亲呢。于是修改Baby的wakeUp方法，即醒来状态改变后，增加一个通知母亲的方法。
综上所述，Baby类做如下几点修改
- 持有Mother的引用，修改构造函数
- 在wakeUp方法中增加，通知母亲的逻辑
- 在run方法中，自己五秒后醒来，自己修改自己的状态
package rjzheng.observer2;
public class Baby implements Runnable {
// 默认是睡着
private boolean wakeup = false;
private Mother mother;
//1. 持有Mother的引用，修改构造函数
public Baby(Mother mother){
this.mother = mother;
}
//2. 在wakeUp方法中增加，通知母亲的逻辑
public void wakeUp() {
wakeup = true;
this.mother.feed(this);
}
public boolean isWakeup() {
return wakeup;
}
public void setWakeup(boolean wakeup) {
this.wakeup = wakeup;
}
//3. 在run方法中，自己五秒后醒来，自己修改自己的状态
@Override
public void run() {
while(!this.isWakeup()){
for(int i=0;i<5;i++){
try {
Thread.sleep(1000);
System.out.println("宝宝还有"+(5-i)+"秒醒来");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
this.wakeUp();
}
}
}而Mother类，则不需要做线程操作，Baby类通知Mother类后，做出相应处理即可。因此，Mother类修改如下
- 删除run方法等线程相关操作
- 增加一个无参构造方法(因为Mother类不需要持有Baby类的引用了)
综上所述，Mother类的代码如下
package rjzheng.observer2;
public class Mother{
private Baby baby;
public Mother(){
}
public Mother(Baby baby) {
this.baby = baby;
}
public void feed(Baby baby){
System.out.println("已经给宝贝喂食");
}
}测试类ObserverTest2的代码如下
package rjzheng.observer2;
public class ObserverTest2 {
public static void main(String[] args) {
Baby baby =new Baby(new Mother());
new Thread(baby).start();
}
}输出如下所示
宝宝还有5秒醒来
宝宝还有4秒醒来
宝宝还有3秒醒来
宝宝还有2秒醒来
宝宝还有1秒醒来
已经给宝贝喂食3、观察者V3
这个时候，宝宝的父亲回来了。父亲觉得，在宝宝醒来后，应该带宝宝出去玩。于是就和孩子他妈约定，根据孩子醒来的时间决定，带孩子做什么。如果醒来的时间是饭点，就给孩子喂食；如果醒来的时间不是饭点，就带孩子出去玩。
那么重点来了，醒来的时间是否为饭点这个属性，放在父亲类里，不大合适；放在宝宝类里也不大合适；放母亲类里也不大合适。根据面向对象的设计原则，我们定义一个醒来的事件类WakeUpEvent,将醒来的时间是否为饭点放在WakeUpEvent里。除此之外，再定义一个事件源source属性，那么WakeUpEvent类如下所示
package rjzheng.observer3;
/**
* 醒来的事件对象
* @author zhengrongjun
*
*/
public class WakeUpEvent {
//醒来时间是否为饭点
private boolean isFoodTime;
//事件源
private Baby source;
public WakeUpEvent(boolean isFoodTime,Baby source){
this.isFoodTime = isFoodTime;
this.source = source;
}
public boolean isFoodTime() {
return isFoodTime;
}
public void setFoodTime(boolean isFoodTime) {
this.isFoodTime = isFoodTime;
}
public Baby getSource() {
return source;
}
public void setSource(Baby source) {
this.source = source;
}
}
那么，接下来,Father类拥有一个带宝贝出去玩的方法，如下所示
package rjzheng.observer3;
public class Father {
public void play(WakeUpEvent wakeUpEvent){
if(!wakeUpEvent.isFoodTime()){
System.out.println("抱宝贝出去玩");
}
}
}
自然，Mother类拥有一个给宝贝喂食的方法，如下所示
package rjzheng.observer3;
public class Mother{
public void feed(WakeUpEvent wakeUpEvent){
if(wakeUpEvent.isFoodTime()){
System.out.println("给宝贝喂食");
}
}
}那么在这种情况下Baby类修改为如下所示
package rjzheng.observer3;
public class Baby implements Runnable {
private Mother mother;
private Father father;
public Baby(Mother mother,Father father) {
this.mother = mother;
this.father = father;
}
public void wakeUp() {
this.mother.feed(new WakeUpEvent(true, this));
this.father.play(new WakeUpEvent(true, this));
}
@Override
public void run() {
boolean flag = true;
while (flag) {
for (int i = 0; i < 5; i++) {
try {
Thread.sleep(1000);
System.out.println("宝宝还有" + (5 - i) + "秒醒来");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
this.wakeUp();
flag=false;
}
}
}测试类ObserverTest3如下所示
package rjzheng.observer3;
public class ObserverTest3 {
public static void main(String[] args) {
Baby baby =new Baby(new Mother(),new Father());
new Thread(baby).start();
}
}运行结果如下
宝宝还有5秒醒来
宝宝还有4秒醒来
宝宝还有3秒醒来
宝宝还有2秒醒来
宝宝还有1秒醒来
给宝贝喂食4、观察者V4
这时情景变为下图
又过了几天，孩子不乐意了。。。。孩子觉得，我每次还要去记爸爸能带我干嘛，妈妈能带我干嘛，太麻烦了。以后，爷爷奶奶来来了，我难道还要去记你们能干嘛，再通知相应的人嘛。不如这样，我把你们全部叫来，你们自己商量好，该带我干嘛吧。
OK。。这也是观察者V3版的缺点，代码复用性太差。如果多一个爷爷GrandFather类，那Baby类里头还要多一个Grandfather类的引用，并且在wakeup里增加通知逻辑，太麻烦。索性，定义一个WakeUpListener接口，继承这个接口的人，代表都具有处理WakeUpEvent事件的能力
那么WakeUpListener接口的源码如下
package rjzheng.observer4;
public interface WakeUpListener {
public void actiontoWakenUp(WakeUpEvent wakeUpEvent);
}这时Father类和Mother类代码如下，都实现了WakeUpListener接口
package rjzheng.observer4;
public class Father implements WakeUpListener {
@Override
public void actiontoWakenUp(WakeUpEvent wakeUpEvent) {
// TODO Auto-generated method stub
if(!wakeUpEvent.isFoodTime()){
System.out.println("抱宝贝出去玩");
}
}
}package rjzheng.observer4;
public class Mother implements WakeUpListener{
@Override
public void actiontoWakenUp(WakeUpEvent wakeUpEvent) {
if(wakeUpEvent.isFoodTime()){
System.out.println("给宝贝喂食");
}
}
}这时的Baby类如下所示
package rjzheng.observer4;
import java.util.ArrayList;
import java.util.List;
public class Baby implements Runnable {
private List<WakeUpListener> wakeUpListeners = new ArrayList();
public void addListeners(WakeUpListener wakeUpListener){
this.wakeUpListeners.add(wakeUpListener);
}
public void wakeUp() {
for(WakeUpListener listener : wakeUpListeners)
listener.actiontoWakenUp(new WakeUpEvent(true, this));
}
@Override
public void run() {
boolean flag = true;
while (flag) {
for (int i = 0; i < 5; i++) {
try {
Thread.sleep(1000);
System.out.println("宝宝还有" + (5 - i) + "秒醒来");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
this.wakeUp();
flag=false;
}
}
}测试类ObserverTest4为
package rjzheng.observer4;
public class ObserverTest4 {
public static void main(String[] args) {
Baby baby =new Baby();
baby.addListeners(new Father());
baby.addListeners(new Mother());
new Thread(baby).start();
}
}最后结果如下
宝宝还有5秒醒来
宝宝还有4秒醒来
宝宝还有3秒醒来
宝宝还有2秒醒来
宝宝还有1秒醒来
给宝贝喂食总结
本篇文章给出了四种观察者模式，一般都是用V4版啦。。前面V1,V2,V3都只是铺垫，为了引出最后一版的观察者模式，希望大家有所收获。
【原创】自己动手实现牛逼的单例模式
引言
其实写这篇文章之前，我犹豫了一下，毕竟单例大家都知道，写这么一篇文章会不会让人觉得老掉牙。后来想想，就当一种记录吧。先来一副漫画吧，如下图所示
ok，我们回顾下小灰的遭遇，上述漫画所提出的那些问题主要有以下三点：
- 为什么静态内部类的单例模式是最推荐的？
- 如何在反射的情况下保证单例？
- 如何在反序列化中保证单例？
针对上述三个问题有了这篇文章，以一种循序渐进的方式，引出最后一种单例设计模式，希望对大家能够有所帮助。
单例设计模式
1、饿汉式
这种其实大家都懂，不多说，上代码。
package singleton;
public class Singleton1 {
private static Singleton1 instance = new Singleton1();
private Singleton1 (){}
public static Singleton1 getInstance() {
return instance;
}
}优点就是线程安全啦，缺点很明显，类加载的时候就实例化对象了，浪费空间。于是乎，就提出了懒汉式的单例模式
2、懒汉式
（1）懒汉式v1
package singleton;
public class LazySingleton1 {
private static LazySingleton1 instance;
private LazySingleton1 (){}
public static LazySingleton1 getInstance() {
if (instance == null) {
instance = new LazySingleton1();
}
return instance;
}
然而这一版线程是不安全的，于是乎为了线程安全，就在getInstance()方法上加synchronized修饰符，于是getInstance()方法如下所示
public static synchronized LazySingleton1 getInstance() {
if (instance == null) {
instance = new LazySingleton1();
}
return instance;
}然而，将synchronized加在方法上性能大打折扣（syncrhonized会造成线程阻塞），于是乎又提出一种双重校验锁的单例设计模式，既保证了线程安全，又提高了性能。双重校验锁的getInstance()方法如下所示
public static LazySingleton1 getInstance() {
if (instance == null) {
synchronized (LazySingleton1.class) {
if (instance == null) {
instance = new LazySingleton1();
}
}
}
return instance;
}
（2）懒汉式v2
懒汉式v1的最后一个双重校验锁版，不管性能再如何优越，还是使用了synchronized修饰符，既然使用了该修饰符，那么对性能多多少少都会造成一些影响，于是乎懒汉式v2版诞生。不过在讲该版之前，我们先来复习一下内部类的加载机制，代码如下
package test;
public class OuterTest {
static {
System.out.println("load outer class...");
}
// 静态内部类
static class StaticInnerTest {
static {
System.out.println("load static inner class...");
}
static void staticInnerMethod() {
System.out.println("static inner method...");
}
}
public static void main(String[] args) {
OuterTest outerTest = new OuterTest(); // 此刻其内部类是否也会被加载？
System.out.println("===========分割线===========");
OuterTest.StaticInnerTest.staticInnerMethod(); // 调用内部类的静态方法
}
}输出如下
load outer class...
===========分割线===========
load static inner class...
static inner method因此，我们有如下结论
- 加载一个类时，其内部类不会同时被加载。
- 一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。。
基于上述结论，我们有了懒汉式V2版，代码如下所示
package singleton;
public class LazySingleton2 {
private LazySingleton2() {
}
static class SingletonHolder {
private static final LazySingleton2 instance = new LazySingleton2();
}
public static LazySingleton2 getInstance() {
return SingletonHolder.instance;
}
}
由于对象实例化是在内部类加载的时候构建的，因此该版是线程安全的(因为在方法中创建对象，才存在并发问题，静态内部类随着方法调用而被加载，只加载一次，不存在并发问题，所以是线程安全的)。另外，在getInstance()方法中没有使用synchronized关键字，因此没有造成多余的性能损耗。当LazySingleton2类加载的时候，其静态内部类SingletonHolder并没有被加载，因此instance对象并没有构建。而我们在调用LazySingleton2.getInstance()方法时，内部类SingletonHolder被加载，此时单例对象才被构建。因此，这种写法节约空间，达到懒加载的目的，该版也是众多博客中的推荐版本。
ps:其实枚举单例模式也有类似的性能，但是因为可读性的原因，并不是最推荐的版本。
（3）懒汉式v3
然而，懒汉式v2版在反射的作用下，单例结构是会被破坏的，测试代码如下所示
package test;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import singleton.LazySingleton2;
/**
* @author zhengrongjun
*/
public class LazySingleton2Test {
public static void main(String[] args) {
//创建第一个实例
LazySingleton2 instance1 = LazySingleton2.getInstance();
//通过反射创建第二个实例
LazySingleton2 instance2 = null;
try {
Class<LazySingleton2> clazz = LazySingleton2.class;
Constructor<LazySingleton2> cons = clazz.getDeclaredConstructor();
cons.setAccessible(true);
instance2 = cons.newInstance();
} catch (Exception e) {
e.printStackTrace();
}
//检查两个实例的hash值
System.out.println("Instance 1 hash:" + instance1.hashCode());
System.out.println("Instance 2 hash:" + instance2.hashCode());
}
}
输出如下
Instance 1 hash:1694819250
Instance 2 hash:1365202186根据哈希值可以看出，反射破坏了单例的特性，因此懒汉式V3版诞生了
package singleton;
public class LazySingleton3 {
private static boolean initialized = false;
private LazySingleton3() {
synchronized (LazySingleton3.class) {
if (initialized == false) {
initialized = !initialized;
} else {
throw new RuntimeException("单例已被破坏");
}
}
}
static class SingletonHolder {
private static final LazySingleton3 instance = new LazySingleton3();
}
public static LazySingleton3 getInstance() {
return SingletonHolder.instance;
}
}此时再运行一次测试类，出现如下提示
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at test.LazySingleton3Test.main(LazySingleton3Test.java:21)
Caused by: java.lang.RuntimeException: 单例已被破坏
at singleton.LazySingleton3.<init>(LazySingleton3.java:12)
... 5 more
Instance 1 hash:359023572这里就保证了，反射无法破坏其单例特性
（3）懒汉式v4
在分布式系统中，有些情况下你需要在单例类中实现 Serializable 接口。这样你可以在文件系统中存储它的状态并且在稍后的某一时间点取出。
让我们测试这个懒汉式V3版在序列化和反序列化之后是否仍然保持单例。
先将
public class LazySingleton3修改为
public class LazySingleton3 implements Serializable 上测试类如下
package test;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
import singleton.LazySingleton3;
public class LazySingleton3Test {
public static void main(String[] args) {
try {
LazySingleton3 instance1 = LazySingleton3.getInstance();
ObjectOutput out = null;
out = new ObjectOutputStream(new FileOutputStream("filename.ser"));
out.writeObject(instance1);
out.close();
//deserialize from file to object
ObjectInput in = new ObjectInputStream(new FileInputStream("filename.ser"));
LazySingleton3 instance2 = (LazySingleton3) in.readObject();
in.close();
System.out.println("instance1 hashCode=" + instance1.hashCode());
System.out.println("instance2 hashCode=" + instance2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
}
输出如下
instance1 hashCode=2051450519
instance2 hashCode=1510067370显然，我们又看到了两个实例类。为了避免此问题，我们需要提供 readResolve() 方法的实现。readResolve(）代替了从流中读取对象。这就确保了在序列化和反序列化的过程中没人可以创建新的实例。
因此，我们提供懒汉式V4版代码如下
package singleton;
import java.io.Serializable;
public class LazySingleton4 implements Serializable {
private static boolean initialized = false;
private LazySingleton4() {
synchronized (LazySingleton4.class) {
if (initialized == false) {
initialized = !initialized;
} else {
throw new RuntimeException("单例已被破坏");
}
}
}
static class SingletonHolder {
private static final LazySingleton4 instance = new LazySingleton4();
}
public static LazySingleton4 getInstance() {
return SingletonHolder.instance;
}
private Object readResolve() {
return getInstance();
}
}
此时，在运行测试类，输出如下
instance1 hashCode=2051450519
instance2 hashCode=2051450519这表示此时已能保证序列化和反序列化的对象是一致的
总结
本文给出了多个版本的单例模式，供我们在项目中使用。实际上，我们在实际项目中一般从懒汉式v2、懒汉式v3、懒汉式v4中，根据实际情况三选一即可，并不是非要选择懒汉式v4作为单例来实现。
最后，希望大家有所收获。
【原创】自己动手实现牛逼的单例模式
引言
其实写这篇文章之前，我犹豫了一下，毕竟单例大家都知道，写这么一篇文章会不会让人觉得老掉牙。后来想想，就当一种记录吧。先来一副漫画吧，如下图所示
ok，我们回顾下小灰的遭遇，上述漫画所提出的那些问题主要有以下三点：
- 为什么静态内部类的单例模式是最推荐的？
- 如何在反射的情况下保证单例？
- 如何在反序列化中保证单例？
针对上述三个问题有了这篇文章，以一种循序渐进的方式，引出最后一种单例设计模式，希望对大家能够有所帮助。
单例设计模式
1、饿汉式
这种其实大家都懂，不多说，上代码。
package singleton;
public class Singleton1 {
private static Singleton1 instance = new Singleton1();
private Singleton1 (){}
public static Singleton1 getInstance() {
return instance;
}
}优点就是线程安全啦，缺点很明显，类加载的时候就实例化对象了，浪费空间。于是乎，就提出了懒汉式的单例模式
2、懒汉式
（1）懒汉式v1
package singleton;
public class LazySingleton1 {
private static LazySingleton1 instance;
private LazySingleton1 (){}
public static LazySingleton1 getInstance() {
if (instance == null) {
instance = new LazySingleton1();
}
return instance;
}
然而这一版线程是不安全的，于是乎为了线程安全，就在getInstance()方法上加synchronized修饰符，于是getInstance()方法如下所示
public static synchronized LazySingleton1 getInstance() {
if (instance == null) {
instance = new LazySingleton1();
}
return instance;
}然而，将synchronized加在方法上性能大打折扣（syncrhonized会造成线程阻塞），于是乎又提出一种双重校验锁的单例设计模式，既保证了线程安全，又提高了性能。双重校验锁的getInstance()方法如下所示
public static LazySingleton1 getInstance() {
if (instance == null) {
synchronized (LazySingleton1.class) {
if (instance == null) {
instance = new LazySingleton1();
}
}
}
return instance;
}
（2）懒汉式v2
懒汉式v1的最后一个双重校验锁版，不管性能再如何优越，还是使用了synchronized修饰符，既然使用了该修饰符，那么对性能多多少少都会造成一些影响，于是乎懒汉式v2版诞生。不过在讲该版之前，我们先来复习一下内部类的加载机制，代码如下
package test;
public class OuterTest {
static {
System.out.println("load outer class...");
}
// 静态内部类
static class StaticInnerTest {
static {
System.out.println("load static inner class...");
}
static void staticInnerMethod() {
System.out.println("static inner method...");
}
}
public static void main(String[] args) {
OuterTest outerTest = new OuterTest(); // 此刻其内部类是否也会被加载？
System.out.println("===========分割线===========");
OuterTest.StaticInnerTest.staticInnerMethod(); // 调用内部类的静态方法
}
}输出如下
load outer class...
===========分割线===========
load static inner class...
static inner method因此，我们有如下结论
- 加载一个类时，其内部类不会同时被加载。
- 一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。。
基于上述结论，我们有了懒汉式V2版，代码如下所示
package singleton;
public class LazySingleton2 {
private LazySingleton2() {
}
static class SingletonHolder {
private static final LazySingleton2 instance = new LazySingleton2();
}
public static LazySingleton2 getInstance() {
return SingletonHolder.instance;
}
}
由于对象实例化是在内部类加载的时候构建的，因此该版是线程安全的(因为在方法中创建对象，才存在并发问题，静态内部类随着方法调用而被加载，只加载一次，不存在并发问题，所以是线程安全的)。另外，在getInstance()方法中没有使用synchronized关键字，因此没有造成多余的性能损耗。当LazySingleton2类加载的时候，其静态内部类SingletonHolder并没有被加载，因此instance对象并没有构建。而我们在调用LazySingleton2.getInstance()方法时，内部类SingletonHolder被加载，此时单例对象才被构建。因此，这种写法节约空间，达到懒加载的目的，该版也是众多博客中的推荐版本。
ps:其实枚举单例模式也有类似的性能，但是因为可读性的原因，并不是最推荐的版本。
（3）懒汉式v3
然而，懒汉式v2版在反射的作用下，单例结构是会被破坏的，测试代码如下所示
package test;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import singleton.LazySingleton2;
/**
* @author zhengrongjun
*/
public class LazySingleton2Test {
public static void main(String[] args) {
//创建第一个实例
LazySingleton2 instance1 = LazySingleton2.getInstance();
//通过反射创建第二个实例
LazySingleton2 instance2 = null;
try {
Class<LazySingleton2> clazz = LazySingleton2.class;
Constructor<LazySingleton2> cons = clazz.getDeclaredConstructor();
cons.setAccessible(true);
instance2 = cons.newInstance();
} catch (Exception e) {
e.printStackTrace();
}
//检查两个实例的hash值
System.out.println("Instance 1 hash:" + instance1.hashCode());
System.out.println("Instance 2 hash:" + instance2.hashCode());
}
}
输出如下
Instance 1 hash:1694819250
Instance 2 hash:1365202186根据哈希值可以看出，反射破坏了单例的特性，因此懒汉式V3版诞生了
package singleton;
public class LazySingleton3 {
private static boolean initialized = false;
private LazySingleton3() {
synchronized (LazySingleton3.class) {
if (initialized == false) {
initialized = !initialized;
} else {
throw new RuntimeException("单例已被破坏");
}
}
}
static class SingletonHolder {
private static final LazySingleton3 instance = new LazySingleton3();
}
public static LazySingleton3 getInstance() {
return SingletonHolder.instance;
}
}此时再运行一次测试类，出现如下提示
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at test.LazySingleton3Test.main(LazySingleton3Test.java:21)
Caused by: java.lang.RuntimeException: 单例已被破坏
at singleton.LazySingleton3.<init>(LazySingleton3.java:12)
... 5 more
Instance 1 hash:359023572这里就保证了，反射无法破坏其单例特性
（3）懒汉式v4
在分布式系统中，有些情况下你需要在单例类中实现 Serializable 接口。这样你可以在文件系统中存储它的状态并且在稍后的某一时间点取出。
让我们测试这个懒汉式V3版在序列化和反序列化之后是否仍然保持单例。
先将
public class LazySingleton3修改为
public class LazySingleton3 implements Serializable 上测试类如下
package test;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
import singleton.LazySingleton3;
public class LazySingleton3Test {
public static void main(String[] args) {
try {
LazySingleton3 instance1 = LazySingleton3.getInstance();
ObjectOutput out = null;
out = new ObjectOutputStream(new FileOutputStream("filename.ser"));
out.writeObject(instance1);
out.close();
//deserialize from file to object
ObjectInput in = new ObjectInputStream(new FileInputStream("filename.ser"));
LazySingleton3 instance2 = (LazySingleton3) in.readObject();
in.close();
System.out.println("instance1 hashCode=" + instance1.hashCode());
System.out.println("instance2 hashCode=" + instance2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
}
输出如下
instance1 hashCode=2051450519
instance2 hashCode=1510067370显然，我们又看到了两个实例类。为了避免此问题，我们需要提供 readResolve() 方法的实现。readResolve(）代替了从流中读取对象。这就确保了在序列化和反序列化的过程中没人可以创建新的实例。
因此，我们提供懒汉式V4版代码如下
package singleton;
import java.io.Serializable;
public class LazySingleton4 implements Serializable {
private static boolean initialized = false;
private LazySingleton4() {
synchronized (LazySingleton4.class) {
if (initialized == false) {
initialized = !initialized;
} else {
throw new RuntimeException("单例已被破坏");
}
}
}
static class SingletonHolder {
private static final LazySingleton4 instance = new LazySingleton4();
}
public static LazySingleton4 getInstance() {
return SingletonHolder.instance;
}
private Object readResolve() {
return getInstance();
}
}
此时，在运行测试类，输出如下
instance1 hashCode=2051450519
instance2 hashCode=2051450519这表示此时已能保证序列化和反序列化的对象是一致的
总结
本文给出了多个版本的单例模式，供我们在项目中使用。实际上，我们在实际项目中一般从懒汉式v2、懒汉式v3、懒汉式v4中，根据实际情况三选一即可，并不是非要选择懒汉式v4作为单例来实现。
最后，希望大家有所收获。
