setChanged 这个开关的作用——可以借鉴思想
1、使得主题具备了很大的伸缩性
假如没有 setChanged,那么一旦主题的状态变了,就不得不立即通知订阅者,这不是很合理,需要一个缓冲——setChanged,如JDK一样,在notify方法中做判断,如果状态的变化达到了一个阈值,在设置 setChanged 条件,这时候才会真的通知,这个条件以及阈值的设置可以在主题类(继承了Observalbe类)的业务代码中实现。
JDK还提供了配套的检查该标志的方法。
2、能筛选订阅者
只有有效通知可以调用 setChanged。比如,微信朋友圈的一条状态,好友 A 点赞,后续该状态的点赞和评论并不是每条都通知 A,只有 A 的好友触发的操作才会通知A——好友才会调用setChanged,这个业务逻辑就可以借鉴JDK
3、能实现通知的撤销
主题中可以设置很多次的 setChanged,比如在一个事务中,在最后由于某种原因,事务失败,那么通知也必须取消,此时可以使用 clearChanged 方法轻松解决问题
4、主题的主动权控制
setChanged 和 clearChanged 方法均为 protected,而 notifyObservers 方法为 public,这就导致存在外部随意调用 notifyObservers 的可能,但是外部无法调用 setChanged,因此真正的控制权属于主题——即使外部能调用主题的通知方法,也是然并卵的
备忘录模式的简单应用——实现无锁的线程安全
主题类即使在清理了状态位之后就释放锁,但是并不影响通知方法的线程安全性,因为加锁之前已经将观察者的列表复制到了一个临时数组 arrLocal——数组是不可变的,局部的。在释放锁后,通知观察者们,但是只通知该临时数组中保存的观察者的们快照,在通知的时候,即使有删除和新的观察者注册,也不会影响通知的过程。
public void notifyObservers(Object arg) {
// 一个临时数组,用于并发访问被观察者时,保存观察者列表的当前状态——这就是基于备忘录模式的简单应用。
Object[] arrLocal;
// 在获取到观察者列表之前,不允许其他线程改变观察者列表
synchronized (this) {
if (!changed)
return;
arrLocal = obs.toArray();
// 重置变化标记位为 false
clearChanged();
}
for (int i = arrLocal.length - 1; i >= 0; i--)
((Observer) arrLocal[i]).update(this, arg);
}
通知方法中的缺陷
上面的实现中,可以发现一个问题,update 是观察者接口中的方法,是各个具体的观察者需要实现的方法, 如果具体观察者的 update 方法有机会抛出异常,那么如果 RD 没有捕获,就会把异常抛出,导致整个通知过程失败,这里也是为什么,不推荐使用该接口。
在自己实现的时候,可以把观察者的 update 方法,用异常控制块包起来,保证通知过程能完整执行。
OOM 的隐患(微不足道)
主题也持有了观察者的引用,如果未正常处理——及时的从主题中删除废弃的观察者,会导致大量的废弃观察者无法被回收。这里其实主要还是业务代码的问题。
如果观察者具体实现代码有问题,可能会导致主题和观察者对象形成循环引用,在某些采用引用计数的垃圾回收器可能导致无法回收。但是,现代GC中,这种问题不会出现,引用计数器算法早已经被放弃使用。
持有观察者的集合类 Vector 的性能问题
先说结论——Vector是最旧的 List 实现,不再推荐使用。
这又是一个槽点,当初实现 JDK 的观察者 API 的时候,可能动态数组用 vector 实现比较好,但是现在早就是推荐使用 Arraylist 了。虽然,vector 与 ArrayList 相似,但是:
1、Vector 是线程安全的list集合
Vector 完全基于 synchronized 实现同步,虽然它的操作与 ArrayList 几乎一样,但是很多时候我们不需要那么重的实现,毕竟加锁会影响性能。故一般直接使用ArrayList,而且,一定要实现线程安全的动态数组,也轮不到用 Vector,可以使用 JUC 中的 CopyOnWriteArraylist 等容器。或者用 Collections 类的同步 List 静态方法来转换为同步List
2、Vector 的部分方法名太长,ArrayList 的对应实现方法名短些,便于阅读,目前仍在使用 Vector 的软件,基本都是为了兼容旧库和懒得改
3、Vector 的容量增长性能很差
Vector 是可变数组,初始 length 是 10 ,如果超过 length 时,会以 100% 比率增长 length,即变成20,所以存在内存浪费的现象,而 Arraylist 的 length 是以 50% 比率增加,所以相比来说,内存使用率较高
主题通知观察者的顺序很奇葩,有bug风险
看源码得知,主题通知观察者的顺序,是 tmd 的倒叙,导致通知观察者的顺序和注册的顺序不一样,如果业务代码对顺序有要求,就不好弄了
主题是类实现的,扩展难
众所周知,Java 没有多继承机制,如果具体主题除了继承主题类外, 还想继承其他业务类,就没法儿写了。典型的违背了”组合(聚合)优于继承的”设计原则。故一般自定义的实现比较多,也不难。虽然 JDK 给我们做了封装,但是很多很多时候,业务需求复杂,JDK 的 API 并不能满足我们的需求。
欢迎关注
dashuai的博客是终身学习践行者,大厂程序员,且专注于工作经验、学习笔记的分享和日常吐槽,包括但不限于互联网行业,附带分享一些PDF电子书,资料,帮忙内推,欢迎拍砖!
Original: https://www.cnblogs.com/kubixuesheng/p/10360194.html
Author: dashuai的博客
Title: JDK 自带的观察者模式源码分析以及和自定义实现的取舍
原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/543221/
转载文章受原作者版权保护。转载请注明原作者出处!