Java 并发简介

钝悟...大约 27 分钟

Java 并发简介

摘要 - 并发编程并非 Java 语言所独有，而是一种成熟的编程范式，Java 只是用自己的方式实现了并发工作模型。学习 Java 并发编程，应该先熟悉并发的基本概念，然后进一步了解并发的特性以及其特性所面临的问题。掌握了这些，当学习 Java 并发工具时，才会明白它们各自是为了解决什么问题，为什么要这样设计。通过这样由点到面的学习方式，更容易融会贯通，将并发知识形成体系化。

什么是并发

技术在进步，CPU、内存、I/O 设备的性能也在不断提高。但是，始终存在一个核心矛盾：CPU、内存、I/O 设备存在很大的速度差异 - CPU 远快于内存，内存远快于 I/O 设备。木桶短板理论告诉我们：一只木桶能装多少水，取决于最短的那块木板。同理，程序整体性能取决于最慢的操作（即 I/O 操作），所以单方面提高 CPU、内存的性能是无效的。

为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系机构、操作系统、编译程序都做出了贡献，主要体现为：

CPU 增加了缓存，以均衡与 CPU 内存的速度差异；
操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 的速度差异；
编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。

其中，进程、线程使得计算机、程序有了并发处理任务的能力。并发是指具备处理多个任务的能力，但不一定要同时。

并发的优点

并发所带来的好处有：

提升资源利用率
程序响应更快

提升资源利用率

想象一下，一个应用程序需要从本地文件系统中读取和处理文件的情景。比方说，从磁盘读取一个文件需要 5 秒，处理一个文件需要 2 秒。处理两个文件则需要：

5 秒读取文件 A
2 秒处理文件 A
5 秒读取文件 B
2 秒处理文件 B
---------------------
总共需要 14 秒

从磁盘中读取文件的时候，大部分的 CPU 时间用于等待磁盘去读取数据。在这段时间里，CPU 非常的空闲。它可以做一些别的事情。通过改变操作的顺序，就能够更好的使用 CPU 资源。看下面的顺序：

5 秒读取文件 A
5 秒读取文件 B + 2 秒处理文件 A
2 秒处理文件 B
---------------------
总共需要 12 秒

CPU 等待第一个文件被读取完。然后开始读取第二个文件。当第二文件在被读取的时候，CPU 会去处理第一个文件。记住，在等待磁盘读取文件的时候，CPU 大部分时间是空闲的。

总的说来，CPU 能够在等待 IO 的时候做一些其他的事情。这个不一定就是磁盘 IO。它也可以是网络的 IO，或者用户输入。通常情况下，网络和磁盘的 IO 比 CPU 和内存的 IO 慢的多。

程序响应更快

将一个单线程应用程序变成多线程应用程序的另一个常见的目的是实现一个响应更快的应用程序。设想一个服务器应用，它在某一个端口监听进来的请求。当一个请求到来时，它去处理这个请求，然后再返回去监听。

服务器的流程如下所述：

while(server is active) {
    listen for request
    process request
}

如果一个请求需要占用大量的时间来处理，在这段时间内新的客户端就无法发送请求给服务端。只有服务器在监听的时候，请求才能被接收。另一种设计是，监听线程把请求传递给工作者线程 (worker thread)，然后立刻返回去监听。而工作者线程则能够处理这个请求并发送一个回复给客户端。这种设计如下所述：

while(server is active) {
    listen for request
    hand request to worker thread
}

这种方式，服务端线程迅速地返回去监听。因此，更多的客户端能够发送请求给服务端。这个服务也变得响应更快。

桌面应用也是同样如此。如果你点击一个按钮开始运行一个耗时的任务，这个线程既要执行任务又要更新窗口和按钮，那么在任务执行的过程中，这个应用程序看起来好像没有反应一样。相反，任务可以传递给工作者线程（worker thread)。当工作者线程在繁忙地处理任务的时候，窗口线程可以自由地响应其他用户的请求。当工作者线程完成任务的时候，它发送信号给窗口线程。窗口线程便可以更新应用程序窗口，并显示任务的结果。对用户而言，这种具有工作者线程设计的程序显得响应速度更快。

任何事物都有利弊，并发也不例外。我们知道了并发带来的好处：提升资源利用率、程序响应更快，同时也要认识到并发带来的问题，主要有：

安全性问题
活跃性问题
性能问题

下面会一一讲解。

安全性问题

并发最重要的问题是并发安全问题。所谓并发安全，是指保证程序的正确性，使得并发处理结果符合预期。

并发安全需要保证几个基本特性：

可见性 - 是一个线程修改了某个共享变量，其状态能够立即被其他线程知晓，通常被解释为将线程本地状态反映到主内存上，volatile 就是负责保证可见性的。
原子性 - 简单说就是相关操作不会中途被其他线程干扰，一般通过同步机制（加锁：sychronized、Lock）实现。
有序性 - 是保证线程内串行语义，避免指令重排等。

缓存导致的可见性问题

一个线程对共享变量的修改，另外一个线程能够立刻看到，称为 可见性。

在单核时代，所有的线程都是在一颗 CPU 上执行，CPU 缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。例如在下面的图中，线程 A 和线程 B 都是操作同一个 CPU 里面的缓存，所以线程 A 更新了变量 V 的值，那么线程 B 之后再访问变量 V，得到的一定是 V 的最新值（线程 A 写过的值）。

多核时代，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。比如下图中，线程 A 操作的是 CPU-1 上的缓存，而线程 B 操作的是 CPU-2 上的缓存，很明显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。

【示例】线程不安全的计数器示例 ❌

@NotThreadSafe
public class NotThreadSafeCounter {

    private static long count = 0;

    private void add() {
        int cnt = 0;
        while (cnt++ < 100000) {
            count += 1;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        final NotThreadSafeCounter demo = new NotThreadSafeCounter();
        // 创建两个线程，执行 add() 操作
        Thread t1 = new Thread(() -> {
            demo.add();
        });
        Thread t2 = new Thread(() -> {
            demo.add();
        });
        // 启动两个线程
        t1.start();
        t2.start();
        // 等待两个线程执行结束
        t1.join();
        t2.join();
        System.out.println("count = " + count);
    }

}
// 输出：
// count = 156602
// 实际结果总是会小于预期值 200000

这段程序的目的是将 count 变量累加到 100000，两个线程执行，则应该累加到 200000，但实际结果总是会小于预期值 200000。

假设线程 A 和线程 B 同时开始执行，那么第一次都会将 count=0 读到各自的 CPU 缓存里，执行完 count+=1 之后，各自 CPU 缓存里的值都是 1，同时写入内存后，我们会发现内存中是 1，而不是我们期望的 2。之后由于各自的 CPU 缓存里都有了 count 的值，两个线程都是基于 CPU 缓存里的 count 值来计算，所以导致最终 count 的值都是小于 20000 的。这就是缓存的可见性问题。

【示例】线程安全的计数器示例 ✔

针对上面线程不安全的计数器最简单的改造方法就是在 add() 方法上增加 synchronized 锁，如下所示：

@ThreadSafe
public class ThreadSafeCounter {
    private synchronized void add() {
        int cnt = 0;
        while (cnt++ < 100000) {
            count += 1;
        }
    }
    // 省略
}

线程切换带来的原子性问题

由于 IO 太慢，早期的操作系统就发明了多进程。CPU 会给各个程序分配一个允许执行时间段，即时间片。从表面上看，各程序是同时运行的；实际上，如果在时间片结束时进程还在运行，则 CPU 将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则 CPU 当即进行切换（称为“任务切换”）。

Java 的并发也是基于任务切换。Java 中，即使是一条语句，也可能需要执行多条 CPU 指令。一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。

CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符。违背直觉的是，高级语言里一条语句往往需要多条 CPU 指令完成，例如上面代码中的count += 1，至少需要三条 CPU 指令。

指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；
指令 2：之后，在寄存器中执行+1 操作；
指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

因此，执行 count += 1 不是原子操作。

编译优化带来的有序性问题

有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：a=6; b=7; 编译器优化后可能变成 b=7; a=6;，在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。不过有时候编译器及解释器的优化可能导致意想不到的 Bug。

在 Java 领域一个经典的案例就是利用双重检查创建单例对象。

【示例】双重检查创建单例对象

public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

假设有两个线程 A、B 同时调用 getInstance() 方法，他们会同时发现 instance == null ，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 A），另外一个线程则会处于等待状态（假设是线程 B）；线程 A 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。

这看上去一切都很完美，无懈可击，但实际上这个 getInstance() 方法并不完美。问题出在哪里呢？出在 new 操作上，我们以为的 new 操作应该是：

分配一块内存 M；
在内存 M 上初始化 Singleton 对象；
然后 M 的地址赋值给 instance 变量。

但是实际上优化后的执行路径却是这样的：

分配一块内存 M；
将 M 的地址赋值给 instance 变量；
最后在内存 M 上初始化 Singleton 对象。

优化后会导致什么问题呢？我们假设线程 A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance() 方法，那么线程 B 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。

保证并发安全的思路

互斥同步（阻塞同步）

互斥同步是最常见的并发正确性保障手段。

同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只能被一个线程访问。

互斥是实现同步的一种手段。临界区（Critical Sections）、互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。

最典型的案例是使用 synchronized 或 Lock 。

互斥同步最主要的问题是线程阻塞和唤醒所带来的性能问题，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。

非阻塞同步

随着硬件指令集的发展，我们可以使用基于冲突检测的乐观并发策略：先进行操作，如果没有其它线程争用共享数据，那操作就成功了，否则采取补偿措施（不断地重试，直到成功为止）。这种乐观的并发策略的许多实现都不需要将线程阻塞，因此这种同步操作称为非阻塞同步。

为什么说乐观锁需要 硬件指令集的发展 才能进行？因为需要操作和冲突检测这两个步骤具备原子性。而这点是由硬件来完成，如果再使用互斥同步来保证就失去意义了。

这类乐观锁指令常见的有：

测试并设置（Test-and-Set）
获取并增加（Fetch-and-Increment）
交换（Swap）
比较并交换（CAS）
加载链接、条件存储（Load-linked / Store-Conditional）

Java 典型应用场景：J.U.C 包中的原子类（基于 Unsafe 类的 CAS 操作）

无同步

要保证线程安全，不一定非要进行同步。同步只是保证共享数据争用时的正确性，如果一个方法本来就不涉及共享数据，那么自然无须同步。

Java 中的 无同步方案 有：

可重入代码 - 也叫纯代码。如果一个方法，它的 返回结果是可以预测的，即只要输入了相同的数据，就能返回相同的结果，那它就满足可重入性，当然也是线程安全的。
线程本地存储 - 使用 ThreadLocal 为共享变量在每个线程中都创建了一个本地副本，这个副本只能被当前线程访问，其他线程无法访问，那么自然是线程安全的。

活跃性问题

程序运行时，当某个操作无法继续执行下去时，就会产生活跃性问题。

对于串行程序，活跃性问题的常见形式是无意中造成的死循环，使得循环之后的代码无法执行。

对于并发程序，会有一些其他的活跃性问题，常见形式有：

死锁
活锁
饥饿

死锁（Deadlock）

什么是死锁

死锁：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

死锁是一种特定的程序状态，在实体之间，由于循环依赖导致彼此一直处于等待之中，没有任何个体可以继续前进。死锁不仅仅是在线程之间会发生，存在资源独占的进程之间同样也可能出现死锁。通常来说，我们大多是聚焦在多线程场景中的死锁，指两个或多个线程之间，由于互相持有对方需要的锁，而永久处于阻塞的状态。

【示例】存在死锁的示例

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 锁定转出账户
    synchronized(this) {
      // 锁定转入账户
      synchronized(target) {
        if (this.balance > amt) {
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  }
}

如何定位死锁

定位死锁最常见的方式就是利用 jstack 等工具获取线程栈，然后定位互相之间的依赖关系，进而找到死锁。如果是比较明显的死锁，往往 jstack 等就能直接定位，类似 JConsole 甚至可以在图形界面进行有限的死锁检测。

如果我们是开发自己的管理工具，需要用更加程序化的方式扫描服务进程、定位死锁，可以考虑使用 Java 提供的标准管理 API，ThreadMXBean，其直接就提供了 findDeadlockedThreads() 方法用于定位。

如何避免死锁

只有以下这四个条件都发生时才会出现死锁：

互斥，共享资源 X 和 Y 只能被一个线程占用；
占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。

也就是说只要破坏任意一个，就可以避免死锁的发生。

其中，互斥这个条件我们没有办法破坏，因为我们用锁为的就是互斥。不过其他三个条件都是有办法破坏掉的，到底如何做呢？

对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。超时释放锁
对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

活锁（Livelock）

什么是活锁

活锁是一个递归的情况，两个或更多的线程会不断重复一个特定的代码逻辑。预期的逻辑通常为其他线程提供机会继续支持'this'线程。

想象这样一个例子：两个人在狭窄的走廊里相遇，二者都很礼貌，试图移到旁边让对方先通过。但是他们最终在没有取得任何进展的情况下左右摇摆，因为他们都在同一时间向相同的方向移动。

如图所示：两个线程想要通过一个 Worker 对象访问共享公共资源的情况，但是当他们看到另一个 Worker（在另一个线程上调用）也是“活动的”时，它们会尝试将该资源交给其他工作者并等待为它完成。如果最初我们让两名工作人员都活跃起来，他们将会面临活锁问题。

避免活锁

解决“活锁”的方案很简单，谦让时，尝试等待一个随机的时间就可以了。由于等待的时间是随机的，所以同时相撞后再次相撞的概率就很低了。“等待一个随机时间”的方案虽然很简单，却非常有效，Raft 这样知名的分布式一致性算法中也用到了它。

饥饿（Starvation）

什么是饥饿

高优先级线程吞噬所有的低优先级线程的 CPU 时间。
线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前持续地对该同步块进行访问。
线程在等待一个本身（在其上调用 wait()) 也处于永久等待完成的对象，因为其他线程总是被持续地获得唤醒。

饥饿问题最经典的例子就是哲学家问题。如图所示：有五个哲学家用餐，每个人要获得两支筷子才可以就餐。当 2、4 就餐时，1、3、5 永远无法就餐，只能看着盘中的美食饥饿的等待着。

解决饥饿

Java 不可能实现 100% 的公平性，我们依然可以通过同步结构在线程间实现公平性的提高。

有三种方案：

保证资源充足
公平地分配资源
避免持有锁的线程长时间执行

这三个方案中，方案一和方案三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。倒是方案二的适用场景相对来说更多一些。

那如何公平地分配资源呢？在并发编程里，主要是使用公平锁。所谓公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

性能问题

并发执行一定比串行执行快吗？线程越多执行越快吗？

答案是：并发不一定比串行快。因为并发过程中，有创建线程和线程上下文切换的开销。

上下文切换

当 CPU 从执行一个线程切换到执行另一个线程时，CPU 需要保存当前线程的本地数据，程序指针等状态，并加载下一个要执行的线程的本地数据，程序指针等。这个开关被称为上下文切换（Context Switch）。

如果频繁地出现上下文切换，将带来极大的开销：恢复执行上下文，丢失局部性，并且 CPU 时间将更多地花在线程调度而不是线程运行上。当线程共享数据时，必须使用同步机制，而这些机制往往会抑制某些编译器优化，使内存缓存区中的数据无效，以及增加共享内存总线的同步流量。所有这些因素都会产生额外的性能开销。

减少上下文切换的方法：

无锁并发编程 - 多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的 ID 按照 Hash 算法取模分段，不同的线程处理不同段的数据。
CAS 算法 - Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁。
使用最少线程 - 避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。
使用协程 - 在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

资源限制

程序的执行速度受限于计算机硬件资源或软件资源。在并发编程中，将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行。但是，如果将某段串行的代码并发执行，因为受限于资源仍然在串行执行，这时候程序不仅不会加快执行，反而会更慢，因为增加了上下文切换和资源调度的时间。

如何解决资源限制的问题呢？在资源受限的情况下，可以根据不同的资源限制调整程序的并发度：

对于硬件资源限制，可以考虑使用集群并行执行程序。
对于软件资源限制，可以考虑使用资源池将资源复用。

并发编程

并发编程可以抽象成三个核心问题：分工、同步、互斥。

分工 - 是指如何高效地拆解任务并分配给线程。
同步 - 是指线程之间如何协作。
互斥 - 是指保证同一时刻只允许一个线程访问共享资源。

J.U.C 简介

Java 的 java.util.concurrent 包（简称 J.U.C）中提供了大量并发工具类，是 Java 并发能力的主要体现（注意，不是全部，有部分并发能力的支持在其他包中）。从功能上，大致可以分为：

原子类 - 如：AtomicInteger、AtomicIntegerArray、AtomicReference、AtomicStampedReference 等。
锁 - 如：ReentrantLock、ReentrantReadWriteLock 等。
并发容器 - 如：ConcurrentHashMap、CopyOnWriteArrayList、CopyOnWriteArraySet 等。
阻塞队列 - 如：ArrayBlockingQueue、LinkedBlockingQueue 等。
非阻塞队列 - 如： ConcurrentLinkedQueue 、LinkedTransferQueue 等。
线程池 - 如：ThreadPoolExecutor、Executors 等。

J.U.C 包中的工具类是基于 synchronized、volatile、CAS、ThreadLocal 这样的并发核心机制打造的。所以，要想深入理解 J.U.C 工具类的特性、为什么具有这样那样的特性，就必须先理解这些核心机制。

并发术语

并发编程中有很多术语概念相近，容易让人混淆。本节内容通过对比分析，力求让读者清晰理解其概念以及差异。

串行、并行、并发

并发和并行是最容易让新手费解的概念，那么如何理解二者呢？其最关键的差异在于：是否是同时发生：

串行 - 是指任务按照顺序依次执行，每个任务在前一个任务完成后才能开始执行。
并行 - 是指具备同时处理多个任务的能力。
并发 - 是指具备处理多个任务的能力，但不一定要同时。

下面是我见过最生动的说明，摘自并发与并行的区别是什么？——知乎的高票答案open in new window：
你吃饭吃到一半，电话来了，你一直到吃完了以后才去接，这就说明你不支持并发也不支持并行。
你吃饭吃到一半，电话来了，你停了下来接了电话，接完后继续吃饭，这说明你支持并发。
你吃饭吃到一半，电话来了，你一边打电话一边吃饭，这说明你支持并行。

同步和异步

同步 - 是指在发出一个调用时，在没有得到结果之前，该调用就不返回。但是一旦调用返回，就得到返回值了。
异步 - 则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。

举例来说明：
同步就像是打电话：不挂电话，通话不会结束。
异步就像是发短信：发完短信后，就可以做其他事；当收到回复短信时，手机会通过铃声或振动来提醒。

阻塞和非阻塞

阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态：

阻塞 - 是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
非阻塞 - 是指在不能立刻得到结果之前，该调用不会阻塞当前线程。

举例来说明：
阻塞调用就像是打电话，通话不结束，不能放下。
非阻塞调用就像是发短信，发完短信后，就可以做其他事，短信来了，手机会提醒。

进程、线程、管程、协程

进程（Process） - 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动。进程是操作系统进行资源分配的基本单位。进程可视为一个正在运行的程序。
线程（Thread） - 线程是操作系统进行调度的基本单位。
管程（Monitor） - 管程是指管理共享变量以及对共享变量的操作过程，让他们支持并发。
- Java 通过 synchronized 关键字及 wait()、notify()、notifyAll() 这三个方法来实现管程技术。
- 管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。
协程（Coroutine） - 协程可以理解为一种轻量级的线程。
- 从操作系统的角度来看，线程是在内核态中调度的，而协程是在用户态调度的，所以相对于线程来说，协程切换的成本更低。
- 协程虽然也有自己的栈，但是相比线程栈要小得多，典型的线程栈大小差不多有 1M，而协程栈的大小往往只有几 K 或者几十 K。所以，无论是从时间维度还是空间维度来看，协程都比线程轻量得多。
- Go、Python、Lua、Kotlin 等语言都支持协程；Java OpenSDK 中的 Loom 项目目标就是支持协程。

进程和线程的差异：

一个程序至少有一个进程，一个进程至少有一个线程。
线程比进程划分更细，所以执行开销更小，并发性更高
进程是一个实体，拥有独立的资源；而同一个进程中的多个线程共享进程的资源。

JVM 在单个进程中运行，JVM 中的线程共享属于该进程的堆。这就是为什么几个线程可以访问同一个对象。线程共享堆并拥有自己的堆栈空间。这是一个线程如何调用一个方法以及它的局部变量是如何保持线程安全的。但是堆不是线程安全的并且为了线程安全必须进行同步。

竞态条件和临界区

竞态条件（Race Condition） - 程序的执行结果依赖多线程执行的顺序。通俗的说，即多个线程竞争访问同一个资源。
临界区（Critical Sections） - 指的是访问共享资源的程序片段。

参考资料

昵称

邮箱

网址

按正序
按倒序
按热度

Java 并发简介

# Java 并发简介

# 什么是并发

# 并发的优点

# 提升资源利用率

# 程序响应更快

# 安全性问题

# 缓存导致的可见性问题

# 线程切换带来的原子性问题

# 编译优化带来的有序性问题

# 保证并发安全的思路

# 互斥同步（阻塞同步）

# 非阻塞同步

# 无同步

# 活跃性问题

# 死锁（Deadlock）

# 什么是死锁

# 如何定位死锁

# 如何避免死锁

# 活锁（Livelock）

# 什么是活锁

# 避免活锁

# 饥饿（Starvation）

# 什么是饥饿

# 解决饥饿

# 性能问题

# 上下文切换

# 资源限制

# 并发编程

# J.U.C 简介

# 并发术语

# 串行、并行、并发

# 同步和异步

# 阻塞和非阻塞

# 进程、线程、管程、协程

# 竞态条件和临界区

# 参考资料

预览:

Java 并发简介

什么是并发

并发的优点

提升资源利用率

程序响应更快

安全性问题

缓存导致的可见性问题

线程切换带来的原子性问题

编译优化带来的有序性问题

保证并发安全的思路

互斥同步（阻塞同步）

非阻塞同步

无同步

活跃性问题

死锁（Deadlock）

什么是死锁

如何定位死锁

如何避免死锁

活锁（Livelock）

什么是活锁

避免活锁

饥饿（Starvation）

什么是饥饿

解决饥饿

性能问题

上下文切换

资源限制

并发编程

J.U.C 简介

并发术语

串行、并行、并发

同步和异步

阻塞和非阻塞

进程、线程、管程、协程

竞态条件和临界区

参考资料