Rxjava Schedulers.newThread（）とSchedulers.io（）による後付け

ネットワークリクエストとSchedulers.newThread()比較Schedulers.io()して使用する利点は何ですかRetrofit。を使用した例をたくさん見てきましたがio()、その理由を理解したいと思います。

状況の例：

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

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

私が見た理由の1つは-

newThread()作業単位ごとに新しいスレッドを作成します。io()スレッドプールを使用します

しかし、その議論がアプリに与える影響は何ですか？そして、他にどのような側面がありますか？

— ミケリス・カネプス
ソース

使用する利点Schedulers.io()は、スレッドプールを使用するのに対し、使用Schedulers.newThread()しないという事実にあるというのは正しいことです。

スレッドプールの使用を検討する必要がある主な理由は、スレッドプールが、アイドル状態で作業を待機している多数の事前に作成されたスレッドを維持することです。つまり、実行する作業がある場合、スレッドを作成するオーバーヘッドを経験する必要はありません。作業が完了すると、そのスレッドは、スレッドを絶えず作成および破棄する代わりに、将来の作業に再利用することもできます。

スレッドの作成にはコストがかかる可能性があるため、通常、オンザフライで作成するスレッドの数を最小限に抑えることをお勧めします。

スレッドプールの詳細については、次のことをお勧めします。

— ブライアン・ハーブスト
ソース

いくつかのユースケースには適さないかもしれない無制限のスレッドプールに基づいているScheduler.io（）についてのコメントを追加する価値があるかもしれません。stackoverflow.com/questions/31276164/を

— Dave Moten 2015年

@DaveMotenどのユースケースが経由のスレッドプールに不適切Schedulers.ioですか？

— IgorGanapolsky 2016年

同時に行う作業が多い場合は、Schedulers.io()OSのI / O制限にぶつかる可能性があります（たとえば、開いているファイルの最大数、信頼性の目的で破棄された後も一定期間開いたままになる可能性のあるtcp接続の最大数）。新しいスレッドごとに、RAMが不足する可能性があるため、最小量のRAM（> 512K、ただし1Mで動作）も必要です。

— デイブモーテン2016年

それらのスレッドは同じメモリを共有していますか？たとえば、あるioスレッドで作成され、別のioスレッドでアクセスされているオブジェクト。

— Eido95 2016年

@ Eido95は、同じスタックではなく、同じヒープを共有します。変数に関する限り、はい、スレッド間で変数を共有できます（これらの変数がスレッドセーフであることを確認することに関するすべての一般的な警告があります）。

— ブライアンハーブスト2016年