概述
并发不一定要依赖多线程（如 PHP 中很常见的多进程并发），但是在 Java 里面谈论并发，大多数都与线程脱不开关系。讲到 Java 线程，就从 Java 线程在虚拟机中的实现开始讲起。
线程的实现
线程时比进程更轻量级的调度执行单位，线程的引入，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源（内存地址、文件 I/O 等），又可以独立调度（线程时 CPU 调度的基本单位）。
我们注意到 Thread 类与大部分的 Java API 有显著的差别，它的所有关键方法都是声明为 Native 的。在 Java API 中，一个 Native 方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现（当然也可能是为了执行效率使用 Native 方法，不过，通常最高效率的手段也就是平台相关的手段）。正因为如此，本节的标题是“线程的实现”，而不是“Java 线程的实现”。
实现线程主要有 3 种方式：使用内核线程实现、使用用户线程实现和使用用户线程和轻量级进程混合实现。
使用内核线程实现
内核线程（Kernel-Level Thread，KTL）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程有内核来完成线程切换，内核通过每个操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核（Multi-Thread Kernel）。
程序一般不会直接使用内核线程，而是去使用内核线程的一种高级接口—轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都有一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。
由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统中阻塞了，也不会影响整个进程继续工作，但是轻量级进程具有它的局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。由系统调用的代价相对较高，需要在用户态（User Model）和内核态（Kernel Model）中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程都需要消耗一定的内核资源（如和线程的栈空间），因此一个系统支持轻量级进程的数量是有限的。
使用用户线程实现
从广义上来讲，一个线程只要不是内核线程，就可以认为是用户线程（User Thread，UT），因此从这个定义上来讲，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作都需要进行系统调用，效率会受到限制。
而狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核，因此操作可以是非常快切消耗低的，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。
使用用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援，所有的线程操作都需要用户程序自己处理。线程创建、切换和调度都需要考虑的问题，而且由于操作系统值把处理器资源分配到进程，那诸如“阻塞如何处理”、“多处理器系统中如何将线程银蛇到其他处理器上”这类问题解决起来将会异常困难，甚至不可能完成。因而使用用户线程实现的程序一般比较复杂，除了以前在不支持多线程的操作系统中（如 DOS）的多线程程序与少数有特殊需求的程序外，现在使用用户线程的程序越来越少了，Java、Ruby 等语言都曾经使用过用户线程，最终又都放弃使用它。
使用用户线程加轻量级进程混合实现
线程除了依赖内核线程实现和完全由用户程序自己实现外，还有一种将内核线程与用户线程一起使用的实现方式。在这种混合实现在，即存在用户线程，也存在轻量级进程。用户线程还可以建立在用户空间上因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供的轻量级进程则可以作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，大大降低了整个进程被完全阻塞的风险。在这种混合模式中，用户线程与轻量级进程的数量比是不定的，即为 N:M 的关系。
许多 UNIX 系列的操作系统，如 Solaris、HP-UX 等都提供了 N:M 的线程模型实现。
Java 线程的实现
Java 线程在 JDK 1.2 之前，是基于称为“绿色线程”（Green Threads）的用户线程实现的，而在 JDK 1.2 中，线程模型替换为基于操作系统远程线程模型来实现。因此，在目前对的 JDK 版本中，操作系统支持怎样的线程模型，在很大程度上决定了 Java 虚拟机的线程时怎样映射的，这点在不同的平台上没有办法达成一致，虚拟机规范中也未限定 Java 线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响，对 Java 程序的编码和运行过程来说，这些差异都是透明的。
对于 Sun JDK 来说，它的 Windows 版与 Linux 版都是使用一对一的线程规模实现的，一条 Java 线程就映射到一条轻量级进程之中，因为 Windows 和 Linux 版系统系统的线程模型都是一对一的。
Java 线程调度
线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种：分别是协同式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling）。
如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把工作执行完以后，要主动通知系统切换到另外一个线程上。协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情处理完以后才会进行线程切换，切换操作对县城自己是可知的，所以没什么线程同步问题。Lua 语言中的“协同例程”就是这类实现。它的坏处也很明显：线程执行时间不可通知，甚至如果一个县城编写有问题，一直不告知系统进行线程切换，那么程序就会一直阻塞在那里。
如果使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不有线程本身来决定（在 Java 中，Thread.yield() 可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的。）在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致真个进程阻塞的问题，Java 使用的线程调度方式就是抢占式调度。
虽然 Java 线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配一点执行时间，另外一些线程则可以少分配一点—这项操作可以通过设置线程优先级来完成。Java 语言一共设置了 10 个级别的线程优先级（Thread.MIN_PRIORITY 至 Thread.MAX_PRIORITY)，在两个线程同时处于 Ready 状态时，优先级越高的线程，越容易被系统选择执行。
不过，线程优先级并不是太靠谱，原因是 Java 的线程时映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统，虽然现在很多操作系统都提供了线程优先级的概念，但是并不见得与 Java 线程的优先级一一对应。还有一种情况让我们不能太依赖优先级：优先级可能会被系统自行改变。
状态转换
Java 语言提供了 5 中线程状态，在任意一个时间点，一个县城只能有其中的一种状态，这 5 中状态分别如下：
- 新建（New）：创建后尚未启动的线程处于这种状态。
- 运行（Runnable）：Runnable 包括了操作系统线程状态中的 Running 和 Ready ，也就是处于此状态的线程可能正在执行，也可能正在等待着 CPU 为它分配执行时间。
无限期等待（Waiting）：处于这种状态的线程不会被分配 CPU 执行时间，它们需要等待被其他线程显式地唤醒。以下方法会让线程陷入无限期等待状态：
- 没有设置 Timeout 参数的 Object.wait() 方法。
- 没有设置 Timeout 参数的 Thread.join() 方法。
- LockSupport.park() 方法。
期限等待（Timed Waiting）：处于这种状态的线程也不会被分配 CPU 执行时间，不过无需登台被他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态：
- Thread.sleep() 方法。
- 设置了 Timeout 参数的 Object.wait() 方法。
- 设置了 Timeout 参数的 Thread.join() 方法。
LockSupport.parkNanos() 方法。
- LockSupport.parkUntil() 方法。
- 阻塞（Blocked）：线程被阻塞了，“线程状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态“则是等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这个状态。
- 结束（Terminated）：已终止线程的线程状态，线程已经结束执行。
