並發不一定要依賴多線程（如PHP中很常見的多進程並發）。
線程的實現
各個線程既可以共享進程資源（內存地址、文件I/O等），又可以獨立調度（線程是CPU調度的基本單位）。
每個已經執行start()且還未結束的java.lang.Thread類的實例就代表了一個線程。Thread的所有關鍵方法都是聲明為Native的。在Java API中，一個Native方法往往意味著這個方法沒有使用或無法使用平台無關的手段來實現（當然也可能是為了執行效率而使用Native方法，不過，通常最高效的手段也就是平台相關的手段）。
實現線程主要有3種方式：
1）使用內核線程實現
2）使用用戶線程實現
3）使用用戶線程加輕量級進程混合實現
使用內核線程（Kernel-Level Thread，KLT）實現
內核線程就是直接由操作系統內核（Kernel）支持的線程，這種線程由內核來完成線程切換，內核通過操縱調度器（Scheduler）對線程進行調度，並負責將線程的任務映射到各個處理器上。每個內核線程可以視為內核的一個分身，這樣操作系統就有能力同時處理多件事情，支持多線程的內核就叫做多線程內核（Multi-Threads Kernel）。
程序一般不會直接去使用內核線程，而是去使用內核線程的一種高級接口--輕量級進程（Light Weight Process，LWP），輕量級進程就是我們通常意義上所講的線程，由於每個輕量級進程都由一個內核線程支持，因此只有先支持內核線程，才能有輕量級進程。這種輕量級進程與內核線程之間1:1的關系稱為一對一的線程模型。
輕量級進程與內核線程之間1:1的關系：
由於內核線程的支持，每個輕量級進程都成為一個獨立的調度單元，即使有一個輕量級進程在系統調用中阻塞了，也不會影響整個進程繼續工作，但是輕量級進程具有它的局限性：首先，由於是基於內核線程實現的，所以各種線程操作，如創建、析構及同步，都需要進行系統調用。而系統調用的代價相對較高，需要在用戶態（User Mode）和內核態（Kernel Mode）中來回切換。其次，每個輕量級進程都需要有一個內核線程的支持，因此輕量級進程要消耗一定的內核資源（如內核線程的棧空間），因此一個系統支持輕量級進程的數量是有限的。
使用用戶線程實現
從廣義上來講，一個線程只要不是內核線程，就可以認為是用戶線程（User Thread，UT），輕量級進程也屬於用戶線程，但輕量級進程的實現始終是建立在內核之上的，許多操作都要進行系統調用，效率會受到限制。
而狹義上的用戶線程指的是完全建立在用戶空間的線程庫上，系統內核不能感知線程存在的實現。用戶線程的建立、同步、銷毀和調度完全在用戶態中完成，不需要內核的幫助。如果程序實現得當，這種線程不需要切換到內核態，因此操作可以是非常快速且低消耗的，也可以支持規模更大的線程數量，部分高性能數據庫中的多線程就是由用戶線程實現的。這種進程與用戶線程之間1:N的關系稱為一對多的線程模型：
使用用戶線程的優勢在於不需要系統內核支援，劣勢也在於沒有系統內核的支援，所有的線程操作都需要用戶程序自己處理。線程的創建、切換和調度都是需要考慮的問題，而且由於操作系統只把處理器資源分配到進程，那諸如“阻塞如何處理”，“多處理器系統中如何將線程映射到其它處理器上”這類問題解決起來將會異常困難，甚至不可能完成。除了以前在不支持多線程的操作系統中（如DOS）的多線程程序與少數有特殊需求的程序外，現在使用用戶線程的程序越來越少了，Java、Ruby等語言都曾經使用過用戶線程，最終又都放棄使用它。
使用用戶線程加輕量級進程混合實現
在這種混合實現下，即存在用戶線程，也存在輕量級進程。用戶線程還是完全建立在用戶空間中，因此用戶線程的創建、切換、析構等操作依然廉價，並且可以支持大規模的用戶線程並發。而操作系統提供支持的輕量級進程則作為用戶線程和內核線程之間的橋梁，這樣可以使用內核提供的線程調度功能及處理器映射，並且用戶線程的系統調用要通過輕量級進程來完成，大大降低了整個進程被完全阻塞的風險。在這種混合模式中，用戶線程與輕量級進程的數量比是不定的，即為N:M的關系：
許多UNIX系列的操作系統，如Salaris、HP-UX等都提供了N:M的線程模型實現。
Java線程的實現
Java線程在JDK1.2之前，是基於稱為“綠色線程”（Green Threads）的用戶線程實現的，而在JDK1.2中，線程模型替換為基於操作系統原生線程模型來實現。因此，在目前的JDK版本中，操作系統支持怎樣的線程模型，在很大程度上決定了Java虛擬機的線程是怎樣映射的，這點在不同的平台上沒有辦法達成一致，虛擬機規范中也並未限定Java線程需要使用哪種線程模型來實現。線程模型只對線程的並發規模和操作成本產生影響，對Java程序的編碼和運行過程來說，這些差異都是透明的。
對於Sun JDK來說，它的Windows版與Linux版都是使用一對一的線程模型實現的，一條Java線程就映射到一條輕量級進程之中，因為Windows和Linux系統提供的線程模型就是一對一的。
而在Solari平台中，由於操作系統的線程特性可以同時支持一對一（通過Bound Threads或Alternate Libthread實現）及一對多（通過LWP/Thread Based Synchronization實現）的線程模型，因此在Solaris版的JDK中也對應提供了兩個平台專有的虛擬機參數：-XX:+UseLWPSynchronization（默認值）和-XX:+UseBoundThreads來明確指定虛擬機使用哪種線程模型。
Java線程調度
線程調度是指系統為線程分配處理器使用權的過程，主要調度方式有兩種：
1）協同式線程調度（Cooperative Threads-Scheduling）
2）搶占式線程調度（Preemptive Threads-Scheduling）
如果使用協同式調度的多線程系統，線程的執行時間由線程本身來控制，線程把自己的工作執行完了之後，要主動通知系統切換到另外一個線程上。協調式線程調度：
好處：
1）實現簡單
2）沒有線程同步問題。由於線程要把自己的事情干完後才會進程線程切換，切換操作對線程自己是可知的，所以沒有什麼線程同步問題。Lua語言中的“協調例程”就是這類實現。
壞處：
1）線程執行時間不可控制
2）甚至如果一個線程編寫有問題，一直不告知系統進行線程切換，那麼程序就會一直阻塞在那裡。很久以前的Windows 3.x系統就是使用協同式來實現多進程多任務的，相當不穩定，一個進程堅持不讓出CPU執行時間就可能會導致整個系統崩潰。
如果使用搶占式調度的多線程系統，那麼每個線程將由系統來分配執行時間，線程的切換不由線程本身來決定（在Java中，Thread.yield()可以讓出執行時間，但是要獲取執行時間的話，線程本身是沒有什麼辦法的）。搶占式線程調度：
好處：
1）線程的執行時間是系統可控的
2）也不會有一個線程導致整個進程阻塞的問題。Java使用的線程調度方式就是搶占式調度。與前面所說的Windows 3.x的例子相對，在Windows 9x/NT內核中就是使用搶占式來實現多進程的，當一個進程出了問題，我們還可以使用任務管理器把這個進程“殺掉”，而不至於導致系統崩潰。
Java語言一共設置了10個級別的線程優先級（Thread.MIN_PRIORITY至Thread.MAX_PRIORITY），在兩個線程同時處於Ready狀態時，優先級越高的線程越容易被系統選擇執行。
不過，線程優先級並不是太靠譜，原因是Java的線程是通過映射到系統的原生線程上來實現的，所以線程調度最終還是取決於操作系統，雖然現在很多操作系統都提供線程優先級的概念，但是並不見得能與Java線程的優先級一一對應。
Solaris中有232種優先級，Windows中只有7種。Windows平台JDK中使用了除THREAD_PRIORITY_IDLE之外的其余6種線程優先級。
Java線程優先級與Windows線程優先級之間的對應關系：
Java線程優先級 Windows線程優先級 1（Thread.MIN_PRIORITY） THREAD_PRIORITY_LOWEST 2 THREAD_PRIORITY_LOWEST 3 THREAD_PRIORITY_BELOW_NORMAL 4 THREAD_PRIORITY_BELOW_NORMAL 5（Thread.NORM_PRIORITY） THREAD_PRIORITY_NORMAL 6 THREAD_PRIORITY_ABOVE_NORMAL 7 THREAD_PRIORITY_ABOVE_NORMAL 8 THREAD_PRIORITY_HIGHEST 9 THREAD_PRIORITY_HIGHEST 10（Thread.MAX_PRIORITY） THREAD_PRIORTIY_CRITICAL上文說到“線程優先級並不是太靠譜”，不僅僅是說在一些平台上不同的優先級實際會變得相同這一點，還有其它情況讓我們不能太依賴優先級：優先級可能會被系統自行改變。例如，在Windows系統中存在一個稱為“優先級推進器”（Priority Boosting，它當然可以被關閉掉）的功能，它的大致作用就是當系統發現一個線程執行的特別“勤奮努力”的話，可能會越過線程優先級去為它分配執行時間。因此，我們不能在程序中通過優先級來完全准確地判斷一組狀態都為Ready的線程將會先執行哪一個。
狀態轉換
線程狀態轉換關系：
Java語言定義了5種線程狀態，在任意一個時間點，一個線程只能有且只有其中的一種狀態，這5種狀態分別如下：
1）新建（New）：創建後尚未啟動的線程處於這種狀態。
2）運行（Runable）：Runable包括了操作系統線程狀態中的Running和Ready，也就是處於此狀態的線程有可能正在執行，也有可能正在等待著CPU為它分配執行時間。
3）無限期等待（Waiting）：處於這種狀態的線程不會被分配CPU執行時間，它們要等待被其它線程顯示地喚醒。以下方法會讓線程陷入無限期的等待狀態：
沒有設置Timeout參數的Object.wait()方法
沒有設置Timeout參數的Thread.join()方法
LockSupport.park()方法
4）限期等待（Timed Waiting）：處於這種狀態的線程也不會被分配CPU執行時間，不過無須等待被其它線程顯示地喚醒，在一定時間之後它們會由系統自動喚醒。以下方法會讓線程進入限期等待狀態：
Thread.sleep()方法
設置了Timeout參數的Object.wait()方法
設置了Timeout參數的Thread.join()方法
LockSupport.parkNanos()方法
LockSupport.parkUntil()方法
5）阻塞（Blocked）：線程被阻塞了，“阻塞狀態”與“等待狀態”的區別是：“阻塞狀態”在等待著獲取到一個排它鎖，這個事件將在另外一個線程放棄這個鎖的時候發生；而“等待狀態”則是在等待一段時間，或者喚醒動作的發生。在程序等待進入同步區域的時候，線程將進入這種狀態。
6）結束（Terminated）：已終止線程的線程狀態，線程已經結束執行。
