RxJava异步销毁CompositeDisposable类源码分析

如果订阅在子线程，响应在主线程，容易发生视图层销毁，而我们的异步操作还没有响应的情况，导致bug或者内存泄露。

RxJava官方提供了```CompositeDisposable```来处理这个问题，但如果不了解他的原理会出现很多使用上的错误，比如如果已经调用过```dispose```函数，很多同学发现，再次add之类的操作全都不灵了，而且clear和dispose到底有什么区别？ 所以有必要研究下设计者的想法，读一下源码

源码非常的简单，只有250多行。仅有的两个属性 是：

第二个很好理解了， 毕竟继承了Dispose接口，这个就是isDisposed回调函数的返回值。

第一个看起来也非常好理解，就是一个容器，我们可以把所有Dispose的实例放到这个容器里。

 

看一下源码最多的判断就是disposed这个变量，我们跟踪一下他的赋值，发现只有一个位置，就是Dispose接口的另一个回调的实现里

线程安全的操作disposed，然后把属性容器resources赋值给set后置空自己，然后拿着set挨个dispose。

可以看到整个类只有这里进行了赋值操作，其他都是读取，可以看到只有调用dispose的时候才会改变这个值，而且只要调用过一次这个方法，很多功能就再也不能使用了，往下看。

可以看到如果已经执行过dispose函数，调用这个add就直接吧作为入参的d也给dispose了，并且返回false。所以dispose不可以随意调用，只有在视图销毁或者再也不打算使用这个实例的时候才可以调用，如果在fragment切换之类的暂时性时机调用，就会出错了。

这里很奇怪的是为什么不直接操作resources？ 直接if（resources == null）resource= new Openhashset(); resources.add(d)感觉更简单啊？这里涉及到一个指令重排序的问题， 因为resources并不是volatile的，cpu可能会乱序执行，但是多线程环境下，简单版的代码，resources读了两次，这两次之间可能他的值就被改变了，而源码只读了一次，读内存操作也是原子性的，所以就不会出现这个问题了。而生命resources为volatile会影响性能，因为对他的操作很多。

 

再看一下clear函数

把resources置空，然后原来存储的挨个dispose了，所以如果复用这个实例的话，应该调用这个函数。