2024年最全容易被忽略的知识点:RxJava操作符的线程安全(1)

(0…numberOfThreads).forEach {

threads += thread(start = false) {

publishSubject.onNext(it)

latch.countDown()

}

}

threads.forEach { it.start() }

latch.await()

check(actuallyReceived.get() == 3)

}

}

执行上面代码,由于take的结果不符合预期,总是会异常退出

看一下take的源码:

public final class ObservableTake extends AbstractObservableWithUpstream<T, T> {

final long limit;

public ObservableTake(ObservableSource source, long limit) {

super(source);

this.limit = limit;

}

protected void subscribeActual(Observer<? super T> observer) {

this.source.subscribe(new ObservableTake.TakeObserver(observer, this.limit));

}

static final class TakeObserver implements Observer, Disposable {

final Observer<? super T> downstream;

boolean done;

Disposable upstream;

long remaining;

TakeObserver(Observer<? super T> actual, long limit) {

this.downstream = actual;

this.remaining = limit;

}

public void onNext(T t) {

if (!this.done && this.remaining-- > 0L) {

boolean stop = this.remaining == 0L;

this.downstream.onNext(t);

if (stop) {

this.onComplete();

}

}

}

}

}

果然不出所料,remaining--没有任何锁操作,无法保证线程安全。

The Observable Contract


Rx在对Observable的定义中已经明确告诉我们了:

Observables must issue notifications to observers serially (not in parallel). They may issue these notifications from different threads, but there must be a formal happens-before relationship between the notifications.

reactivex.io/documentati…

happens-before relationship 需要我们保证进入stream数据的先后顺序,避免并发行为。根据官方的解释,这样做可以避免一些有锁操作带来的性能下降,因此仅在必要的时候才确保线程安全。

操作符的线程安全

那么哪些操作符是线程安全的呢?

RxJava的操作符种类繁多,一个一个记忆很难,基本上可以按照这个原则区分:

  • 操作单个Observable的操作符都不是线程不安全的,例如常用的 take(n)map()distinctUntilChanged() 等,但是带有scheduler参数的除外,例如 window(…, scheduler)debounce(…, scheduler)

  • 操作多个Observable的操作符是线程安全的,例如 merge()combineLatest()zip()

用代码描述大概是这种感觉:

fun operatorThreadSafety() = if (operator.worksWithOneObservable() &&

operator.supportsScheduling == false) {

Operator.NOT_THREAD_SAFE_AND_THAT_IS_OK

} else {

Operator.MOST_LIKELY_THREAD_SAFE

}

Subject的线程安全


相对于操作符的线程安全,个人认为Subject的使用更需要大家注意。常用的Subject都不是线程安全的(SerializedSubject除外),而最容易出现并发操作的场景恰恰是Subject,例如我们经常会使用Subject作为中继器,异步onNext向Subject发射数据。前面take的例子便是这种场景。

更要命的是我们常配合observeOn来进行线程切换,而observeOn本身也并非线程安全的,翻看其源码会发现,observeOn在切线程时使用了一个线程不安全的队列

queue = new SpscArrayQueue(RxRingBuffer.SIZE);

因此,下面的代码在并发环境中必然会发生问题:

@JvmStatic

fun main(args: Array) {

val numberOfThreads = 10000

val publishSubject = PublishSubject.create()

val actuallyReceived = AtomicInteger()

publishSubject

学习路线:

这个方向初期比较容易入门一些,掌握一些基本技术,拿起各种现成的工具就可以开黑了。不过,要想从脚本小子变成黑客大神,这个方向越往后,需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容:
在这里插入图片描述

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以点击这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

  • 29
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值