Retrofit con Rxjava Schedulers.newThread () vs Schedulers.io ()

Quali sono i vantaggi da utilizzare Schedulers.newThread()rispetto Schedulers.io()alla Retrofitrichiesta di rete. Ho visto molti esempi che usano io(), ma voglio capire perché.

Situazione di esempio:

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

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

Uno dei motivi che ho visto è:

newThread()crea un nuovo thread per ogni unità di lavoro. io()utilizzerà un pool di thread

Ma qual è l'influenza di questo argomento sull'app? E quali altri aspetti ci sono?

— Mikelis Kaneps
fonte

Hai ragione sul fatto che il vantaggio dell'utilizzo Schedulers.io()risiede nel fatto che utilizza un pool di thread, mentre Schedulers.newThread()non lo fa.

Il motivo principale per cui dovresti considerare l'utilizzo di pool di thread è che mantengono un numero di thread pre-creati che sono inattivi e in attesa di lavoro. Ciò significa che quando hai del lavoro da fare, non è necessario passare attraverso l'overhead della creazione di un thread. Una volta terminato il tuo lavoro, quel thread può anche essere riutilizzato per lavori futuri invece di creare e distruggere costantemente thread.

I thread possono essere costosi da creare, quindi ridurre al minimo il numero di thread che si creano al volo è generalmente buono.

Per ulteriori informazioni sui pool di thread, consiglio:

— Bryan Herbst
fonte

Potrebbe valere la pena aggiungere un commento su Scheduler.io () basato su un pool di thread illimitato che potrebbe non essere appropriato per alcuni casi d'uso. Vedi stackoverflow.com/questions/31276164/…

— Dave Moten

@DaveMoten Quali casi d'uso non sono appropriati per il pool di thread tramite Schedulers.io?

— IgorGanapolsky

Se hai molto lavoro simultaneo da fare, Schedulers.io()potresti imbatterti nei limiti di i / o del sistema operativo (ad esempio numero massimo di file aperti, numero massimo di connessioni TCP che per motivi di affidabilità possono rimanere aperte per un periodo anche dopo essere state eliminate) . Ogni nuovo thread richiede anche una quantità minima non banale di RAM (> 512K ma funziona su 1M) in modo da poter esaurire la RAM.

— Dave Moten

Quei thread condividono la stessa memoria? es. oggetto creato in un thread io e accessibile in un altro thread io.

— Eido95

@ Eido95 condividono lo stesso mucchio, non lo stesso stack. Per quanto riguarda le variabili, sì, puoi condividere le variabili tra i thread (con tutti i tipici avvertimenti per assicurarti che tali variabili siano thread-safe).

— Bryan Herbst