Sto leggendo di canali nel JDK 7 Documenti (here), e inciampato su questo:Perché "I/O multiplexato, non bloccante, [..] molto più scalabile rispetto a thread-oriented, blocco I/O"?
multiplex, I/O, che è molto più scalabile rispetto filo-oriented, bloccando io non bloccante/O, [...]
Esiste una spiegazione semplice del motivo per cui è così?
"Blocco" significa che i thread devono attendere il tempo necessario a rendere disponibile una risorsa ... il che significa che, per definizione, i thread saranno in attesa di risorse. Il non blocco evita questo tipo di cose.
Generalmente, le soluzioni non bloccanti sono più ingannevoli, ma evitano il conflitto di risorse, il che rende molto più semplice scalare. (Detto questo, il punto di Channel è quello di renderlo meno complicato.)
Poiché uno stack di thread è in genere molto più grande della struttura dati necessaria per supportare una connessione I/O asincrona. Inoltre, la pianificazione di migliaia di thread è inefficiente.
Questo è il solito argomento, ma: posso eseguire decine di migliaia di thread sulla mia macchina desktop, ma non ho ancora visto alcun problema dove potrebbe effettivamente servire decine di migliaia di connessioni da una singola macchina senza che tutto si fermi. Questo mi sembra un argomento debole. Anche NIO non blocca con selettori [non è una scelta così grande spesso] (http://www.mailinator.com/tymaPaulMultithreaded.pdf) – Voo
@Voo: alcune connessioni potrebbero essere inattive per decine di minuti alla volta, ma comunque Aperto. –
@Voo, dubito che tu abbia decine di migliaia di thread eseguibili (non solo al minimo). il cambio di contesto anche a buon mercato è ancora uno sfratto di cache TLB con ulteriori errori di cache. Lavorando su migliaia di connessioni, direi che servire utenti 2k con circa 85.000 messaggi al secondo su due socket xeon richiede una CPU del 20% (di tutti i CPUS) ... Inoltre, NIO consente una consegna del traffico "equa" che è molto importante e molto spesso trascurato in quanto garantisce una latenza stabile per i clienti. (Iirc il benchmark non misura la latenza) – bestsss
L'I/O non bloccante non significa che i thread non attendono, significa semplicemente che l'operazione di attesa è separata dall'operazione I/O. –