使用 Rxjava Schedulers.newThread() 与 Schedulers.io() 进行改造答案

【问题标题】：Retrofit with Rxjava Schedulers.newThread() vs Schedulers.io()使用 Rxjava Schedulers.newThread() 与 Schedulers.io() 进行改造
【发布时间】：2016-01-29 16:36:41
【问题描述】：

在Retrofit 网络请求中使用Schedulers.newThread() 与Schedulers.io() 有什么好处。我见过很多使用io() 的例子，但我想了解原因。

示例情况：

observable.onErrorResumeNext(refreshTokenAndRetry(observable))
    .subscribeOn(Schedulers.newThread())
    .observeOn(AndroidSchedulers.mainThread())...

对

observable.onErrorResumeNext(refreshTokenAndRetry(observable))
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())...

我看到的原因之一是——

newThread() 为每个工作单元创建一个新线程。 io() 将使用线程池

但是该论点对应用程序有什么影响？还有哪些方面？

【问题讨论】：

标签： android retrofit rx-java rx-android

【解决方案1】：

您说得对，使用Schedulers.io() 的好处在于它使用线程池，而Schedulers.newThread() 没有。

您应该考虑使用线程池的主要原因是它们维护了许多预先创建的空闲并等待工作的线程。这意味着当你有工作要做时，你不需要经历创建线程的开销。完成工作后，该线程也可以重新用于未来的工作，而不是不断创建和销毁线程。

创建线程的成本可能很高，因此尽量减少动态创建的线程数量通常是好的。

有关线程池的更多信息，我建议：

【讨论】：

可能值得添加关于 Scheduler.io() 基于无限线程池的评论，这可能不适合某些用例。见stackoverflow.com/questions/31276164/…
@DaveMoten 哪些用例不适用于Schedulers.io 的线程池？
如果你有很多并发工作要处理Schedulers.io()，那么你可能会遇到操作系统 i/o 限制（例如打开文件的最大数量、tcp 连接的最大数量，这是出于可靠性目的即使在被处置后也可能保持开放一段时间）。每个新线程还需要最低限度的重要 RAM（> 512K 但在 1M 上工作），因此您可能会用完 RAM。
这些线程是否共享相同的内存？例如在一个 io 线程中创建并在另一个 io 线程中访问的对象。
@Eido95 他们共享同一个堆，而不是同一个堆栈。就变量而言，是的，您可以在线程之间共享变量（带有所有关于确保这些变量是线程安全的典型警告）。