Allora, per quel poco che ne so...

I thread possono essere gestiti in due modalita': dal SO, o dall'utente.

Se il sistema operativo si occupa della gestione, tutto e' trasparente per l'utente, che deve solo richiamare le primitive messegli a disposizione (tramite apposite interfacce fornite dal linguaggio di programmazione)
Lo svantaggio di questa soluzione e' che il sistema operativo:
a) deve memorizzare informazioni su ogni thread, anziche su ogni processo, rendendo piu' oneroso lo scheduling;
b) deve essere continuamente interpellato per decidere quale thread deve essere eseguito, creando overhead, spreco di tempo: infatti, laddove ci sarebbe la possibilita' di eseguire un altro thread dello stesso processo, sono invece obbligato a interrompere il mio programma, interpellare il SO, il quale fara' lo scheduling (che come abbiamo detto ora e' anche piu' oneroso...) per decidere cosa eseguire, e poi si interrompera' a sua volta per mandare in CPU il thread schedulato;
c) detto questo, bisogna prevedere uno scheduling "equo": se i thread venissero gestiti separatamente, un processo con 100 thread avrebbe cento volte in piu' possibilita' di essere schedulato!

Se l'utente gestisce i thread, non solo puo' decidere da solo quale mandare in esecuzione, ma puo' farlo secondo una politica che puo' differire del tutto da quella adottata dal sistema operativo: ad esempio puo' dare sempre maggiore priorita' ad alcuni thread anziche' altri, laddove il SO prevederebbe l'alternanza "equa" dei processi nella CPU.
Tutto cio' senza cambiare il contesto di esecuzione, visto che i thread condividono sia l'area codice che l'area dati.

In questo secondo caso, se il SO non prevede il supporto dei thread vede l'insieme dei thread (il task) come un unico processo: cio' e' limitativo perche' se un thread si blocca (per esempio potrebbe aver richiesto l'accesso al disco al sistema operativo) si ferma tutto il task!!! Questo perche' il SO non e' in grado di discernere fra un thread e l'altro: sa che quel processo ha richiesto un servizio (es. accedere al disco), sa che non l'ha ancora ottenuto, ergo quel processo non va schedulato fino a quando non esce dallo stato di attesa. Questo problema non ricordo come si risolve... Pero' si risolve!!! ^__^

Veniamo a noi.
In Java i thread sono tecnicamente gestiti dall'utente, dove pero' l'utente e' la Java Virtual Machine che sbriga tutte le rogne che ti ho elencato ed altre ancora!
A te non resta altro che definirli, farli partire, sincronizzarli... Sembra niente!