📝 Writing docs.

dunwu · dunwu · commit 85eef5b54c14 · 2018-05-21T15:26:05.000+08:00
diff --git a/docs/concurrent/并发简介.md b/docs/concurrent/并发简介.md
@@ -0,0 +1,192 @@
+---
+ngtitle: 并发简介
+date: 2018/05/21
+categories:
+- javase
+tags:
+- javase
+- concurrent
+---
+
+# 并发简介
+
+<!-- TOC depthFrom:2 depthTo:4 -->
+
+- [多线程的优点](#多线程的优点)
+- [多线程的风险](#多线程的风险)
+  - [安全性问题](#安全性问题)
+    - [线程不安全的示例](#线程不安全的示例)
+    - [竞态条件和临界区](#竞态条件和临界区)
+  - [活跃性问题](#活跃性问题)
+    - [死锁](#死锁)
+    - [饥饿和公平](#饥饿和公平)
+  - [性能问题](#性能问题)
+    - [上下文切换](#上下文切换)
+    - [资源限制](#资源限制)
+- [资料](#资料)
+
+<!-- /TOC -->
+
+## 多线程的优点
+
+* 更好的资源利用
+* 更简单的编程模型
+* 程序响应更灵敏
+
+## 多线程的风险
+
+凡事有利有弊，引入多线程除了带来的好处以外，也产生了一些问题：
+
+* 安全性问题
+* 活跃性问题
+* 性能问题
+
+### 安全性问题
+
+什么是线程安全？
+
+线程安全很难定义。我所看到的对于线程安全的定义都太过抽象。
+
+所以，我觉得有必要反向理解，知道什么是线程不安全，那么就能定义线程安全的边界了。
+
+在同一程序中运行多个线程本身不会导致问题，问题在于多个线程访问了相同的资源。如：同一内存区（变量，数组，或对象）、系统（数据库，web services 等）或文件。
+
+#### 线程不安全的示例
+
+```java
+public class Counter {
+    protected long count = 0;
+    public void add(long value){
+        this.count = this.count + value;
+    }
+}
+```
+
+想象下线程 A 和 B 同时执行同一个 Counter 对象的 add()方法，我们无法知道操作系统何时会在两个线程之间切换。JVM 并不是将这段代码视为单条指令来执行的，而是按照下面的顺序：
+
+```
+从内存获取 this.count 的值放到寄存器
+将寄存器中的值增加 value
+将寄存器中的值写回内存
+```
+
+观察线程 A 和 B 交错执行会发生什么：
+
+```
+this.count = 0;
+A: 读取 this.count 到一个寄存器 (0)
+B: 读取 this.count 到一个寄存器 (0)
+B: 将寄存器的值加 2
+B: 回写寄存器值(2)到内存. this.count 现在等于 2
+A: 将寄存器的值加 3
+A: 回写寄存器值(3)到内存. this.count 现在等于 3
+```
+
+两个线程分别加了 2 和 3 到 count 变量上，两个线程执行结束后 count 变量的值应该等于 5。然而由于两个线程是交叉执行的，两个线程从内存中读出的初始值都是 0。然后各自加了 2 和 3，并分别写回内存。最终的值并不是期望的 5，而是最后写回内存的那个线程的值，上面例子中最后写回内存的是线程 A，但实际中也可能是线程 B。如果没有采用合适的同步机制，线程间的交叉执行情况就无法预料。
+
+#### 竞态条件和临界区
+
+当两个线程竞争同一资源时，如果对资源的访问顺序敏感，就称存在竞态条件。
+
+导致竞态条件发生的代码区称作临界区。
+
+上例中 add()方法就是一个临界区,它会产生竞态条件。在临界区中使用适当的同步就可以避免竞态条件。
+
+### 活跃性问题
+
+#### 死锁
+
+##### 什么是死锁
+
+多个线程互相等待对方释放锁。
+
+##### 避免死锁的方法
+
+（1）加锁顺序
+
+当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就很容易发生。
+
+如果能确保所有的线程都是按照相同的顺序获得锁，那么死锁就不会发生。
+
+按照顺序加锁是一种有效的死锁预防机制。但是，这种方式需要你事先知道所有可能会用到的锁(译者注：并对这些锁做适当的排序)，但总有些时候是无法预知的。
+
+（2）加锁时限
+
+另外一个可以避免死锁的方法是在尝试获取锁的时候加一个超时时间，这也就意味着在尝试获取锁的过程中若超过了这个时限该线程则放弃对该锁请求。若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。这段随机的等待时间让其它线程有机会尝试获取相同的这些锁，并且让该应用在没有获得锁的时候可以继续运行(译者注：加锁超时后可以先继续运行干点其它事情，再回头来重复之前加锁的逻辑)。
+
+（3）死锁检测
+
+死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
+
+每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph 等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。
+
+当一个线程请求锁失败时，这个线程可以遍历锁的关系图看看是否有死锁发生。
+
+如果检测出死锁，有两种处理手段：
+
+* 释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁（编者注：原因同超时类似，不能从根本上减轻竞争）。
+* 一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。
+
+#### 饥饿和公平
+
+##### 导致饥饿问题的原因
+
+* 高优先级线程吞噬所有的低优先级线程的 CPU 时间。
+* 线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前持续地对该同步块进行访问。
+* 线程在等待一个本身(在其上调用 wait())也处于永久等待完成的对象，因为其他线程总是被持续地获得唤醒。
+
+##### 解决饥饿问题的方法
+
+Java 不可能实现 100% 的公平性，我们依然可以通过同步结构在线程间实现公平性的提高。
+
+* 使用锁，而不是同步块。
+* 公平锁。
+
+### 性能问题
+
+**并发执行一定比串行执行快吗？**
+
+答案是：不一定。因为有创建线程和线程上下文切换的开销。
+
+#### 上下文切换
+
+##### 什么是上下文切换？
+
+当 CPU 从执行一个线程切换到执行另一个线程时，CPU 需要保存当前线程的本地数据，程序指针等状态，并加载下一个要执行的线程的本地数据，程序指针等。这个开关被称为“上下文切换”。
+
+##### 减少上下文切换的方法
+
+* 无锁并发编程 - 多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的 ID 按照 Hash 算法取模分段，不同的线程处理不同段的数据。
+* CAS 算法 - Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁。
+* 使用最少线程 - 避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。
+* 使用协程 - 在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。
+
+#### 资源限制
+
+##### 什么是资源限制
+
+资源限制是指在进行并发编程时，程序的执行速度受限于计算机硬件资源或软件资源。
+
+##### 资源限制引发的问题
+
+在并发编程中，将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行，但是如果将某段串行的代码并发执行，因为受限于资源，仍然在串行执行，这时候程序不仅不会加快执行，反而会更慢，因为增加了上下文切换和资源调度的时间。
+
+##### 如何解决资源限制的问题
+
+在资源限制情况下进行并发编程，根据不同的资源限制调整程序的并发度。
+
+* 对于硬件资源限制，可以考虑使用集群并行执行程序。
+* 对于软件资源限制，可以考虑使用资源池将资源复用。
+
+## 资料
+
+* [Java 并发编程实战](https://item.jd.com/10922250.html)：第 1 章 简介
+* [Java 并发编程的艺术](https://item.jd.com/11740734.html)：第 1 章 Java 并发编程的挑战
+* http://tutorials.jenkov.com/java-concurrency/benefits.html
+* http://tutorials.jenkov.com/java-concurrency/costs.html
+* http://tutorials.jenkov.com/java-concurrency/race-conditions-and-critical-sections.html
+* http://tutorials.jenkov.com/java-concurrency/thread-safety.html
+* http://tutorials.jenkov.com/java-concurrency/thread-safety-and-immutability.html
+* http://tutorials.jenkov.com/java-concurrency/deadlock.html
+* http://tutorials.jenkov.com/java-concurrency/deadlock-prevention.html
+* http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html
