Il pool di thread fork-and-join di Java è utile per eseguire l'attività legata all'IO?

Question

nella mia applicazione, devo risolvere un problema eseguendo molte attività associate a network-io e qualche volta a un compito legato a io e diviso in più piccoli compiti associati. Queste attività vengono attualmente eseguite utilizzando il meccanismo threadpool standard di Java. Mi chiedo se posso passare al framework fork-and-join? Ma la domanda è: il framework forkandjoin di solito viene utilizzato per risolvere le operazioni associate o vincolate alla CPU? Presumo che siano per lo più per operazioni associate alla CPU, perché il framework fork-and-join utilizza la tecnica del furto del lavoro per utilizzare i processori core di multo, ma se lo utilizzo per compiti legati all'IO, ci saranno effetti negativi?

Answer 1

Fork-join è progettato per le attività legate all'elaborazione, quindi in genere direi di no. Fork-join ha un'API (l'API ManagedBlocker) per dire al framework FJ che il thread si bloccherà per un po 'e non per allineare nuove attività ma è davvero progettato per brevi attese (come ottenere un blocco), non arbitrariamente lungo aspetta IO.

Abbiamo un sistema che utilizza fork-join e si spostano le attività legate all'IO in un pool di executor separato. Quando i dati arrivano, attivano le attività nel pool fork-join in modo tale che solo il lavoro con cpu-bound si verifica lì.

Answer 2

Se si sta tentando di affrontare l'aspetto "I/O legato" del problema, dubito che passare da thread standard a fork-and-join migliorerà le cose ... presumendo che tu abbia implementato il attuale soluzione basata su thread correttamente. (E in base alla risposta di Alex Miller, l'interruttore potrebbe effettivamente peggiorare le cose.)

Oppure, per dirla in un altro modo, il modo per rendere più veloce l'applicazione I/O associata è affrontare i problemi che lo rendono necessario/O associato ... o aumenta la larghezza di banda I/O del sistema.

Answer 3

in questo caso non sembra essere un vantaggio convincente per i fork-joins.

non sembra essere uno svantaggio significativo sia perché non si guida una risorsa troppo difficile.

tutto sommato, vorrei rimanere con il pool di thread fino a quando non hai altri sviluppi importanti da fare.