add

note/actualCombat/Limiter.md

@@ -50,7 +50,7 @@
 针对前端重复连续多次点击的情况，例如恶意评论，支付，提交订单的接口就可以通过 Token 的机制实现防止重复提交。
 - 流程图如下:
 
-[token_limiter](img/token_limiter.png)
+![token_limiter](img/token_limiter.png)
 
 整个流程已经完成，但是我们在实际开发的时候还需要制定规则，来判断是否是重复提交
 

note/java/concurrency/README.md

@@ -12,3 +12,5 @@
 - [线程本地存储模式：没有共享，就没有伤害](designpattern/ThreadLocalPattern.md) 
 - [Guarded Suspension模式：等待唤醒机制的规范实现](designpattern/GuardedSuspension.md) 
 - [Balking模式：再谈线程安全的单例模式](designpattern/Balking.md) 
+- [Thread-Per-Message模式：最简单实用的分工方法](designpattern/ThreadPerMessage.md) 
+- [Worker Thread模式：如何避免重复创建线程](designpattern/WorkerThread.md) 

note/java/concurrency/designpattern/ThreadPerMessage.md

@@ -0,0 +1,156 @@
+## Thread-Per-Message模式：最简单实用的分工方法
+
+我们曾经把并发编程领域的问题总结为三个核心问题：分工、同步和互斥。其中，同步和互斥相关问题更多地源自微观，而分工问题则是源自宏观。我们解决问题，往往都是从宏观入手，在编程领域，软件的设计过程也是先从概要设计开始，而后才进行详细设计。同样，解决并发编程问题，首要问题也是解决宏观的分工问题。
+
+并发编程领域里，解决分工问题也有一系列的设计模式，比较常用的主要有 Thread-Per-Message 模式、Worker Thread 模式、生产者 - 消费者模式等等。今天我们重点介绍 Thread-Per-Message 模式。
+
+### 如何理解 Thread-Per-Message 模式
+
+现实世界里，很多事情我们都需要委托他人办理，一方面受限于我们的能力，总有很多搞不定的事，比如教育小朋友，搞不定怎么办呢？只能委托学校老师了；另一方面受限于我们的时间，比如忙着写 Bug，哪有时间买别墅呢？只能委托房产中介了。委托他人代办有一个非常大的好处，那就是可以专心做自己的事了。
+
+在编程领域也有很多类似的需求，比如写一个 HTTP Server，很显然只能在主线程中接收请求，而不能处理 HTTP 请求，因为如果在主线程中处理 HTTP 请求的话，那同一时间只能处理一个请求，太慢了！怎么办呢？可以利用代办的思路，创建一个子线程，委托子线程去处理 HTTP 请求。
+
+这种委托他人办理的方式，在并发编程领域被总结为一种设计模式，叫做 Thread-Per-Message 模式，简言之就是为每个任务分配一个独立的线程。这是一种最简单的分工方法，实现起来也非常简单。
+
+### 用 Thread 实现 Thread-Per-Message 模式
+
+Thread-Per-Message 模式的一个最经典的应用场景是网络编程里服务端的实现，服务端为每个客户端请求创建一个独立的线程，当线程处理完请求后，自动销毁，这是一种最简单的并发处理网络请求的方法。
+
+网络编程里最简单的程序当数 echo 程序了，echo 程序的服务端会原封不动地将客户端的请求发送回客户端。例如，客户端发送 TCP 请求"Hello World"，那么服务端也会返回"Hello World"。
+
+下面我们就以 echo 程序的服务端为例，介绍如何实现 Thread-Per-Message 模式。
+
+在 Java 语言中，实现 echo 程序的服务端还是很简单的。只需要 30 行代码就能够实现，示例代码如下，我们为每个请求都创建了一个 Java 线程，核心代码是：new Thread(()->{…}).start()。
+
+```java
+
+final ServerSocketChannel ssc = 
+  ServerSocketChannel.open().bind(
+    new InetSocketAddress(8080));
+//处理请求    
+try {
+  while (true) {
+    // 接收请求
+    SocketChannel sc = ssc.accept();
+    // 每个请求都创建一个线程
+    new Thread(()->{
+      try {
+        // 读Socket
+        ByteBuffer rb = ByteBuffer
+          .allocateDirect(1024);
+        sc.read(rb);
+        //模拟处理请求
+        Thread.sleep(2000);
+        // 写Socket
+        ByteBuffer wb = 
+          (ByteBuffer)rb.flip();
+        sc.write(wb);
+        // 关闭Socket
+        sc.close();
+      }catch(Exception e){
+        throw new UncheckedIOException(e);
+      }
+    }).start();
+  }
+} finally {
+  ssc.close();
+}   
+```
+
+如果你熟悉网络编程，相信你一定会提出一个很尖锐的问题：上面这个 echo 服务的实现方案是不具备可行性的。原因在于 Java 中的线程是一个重量级的对象，创建成本很高，一方面创建线程比较耗时，另一方面线程占用的内存也比较大。所以，为每个请求创建一个新的线程并不适合高并发场景。
+
+于是，你开始质疑 Thread-Per-Message 模式，而且开始重新思索解决方案，这时候很可能你会想到 Java 提供的线程池。你的这个思路没有问题，但是引入线程池难免会增加复杂度。其实你完全可以换一个角度来思考这个问题，语言、工具、框架本身应该是帮助我们更敏捷地实现方案的，而不是用来否定方案的，Thread-Per-Message 模式作为一种最简单的分工方案，Java 语言支持不了，显然是 Java 语言本身的问题。
+
+Java 语言里，Java 线程是和操作系统线程一一对应的，这种做法本质上是将 Java 线程的调度权完全委托给操作系统，而操作系统在这方面非常成熟，所以这种做法的好处是稳定、可靠，但是也继承了操作系统线程的缺点：创建成本高。为了解决这个缺点，Java 并发包里提供了线程池等工具类。这个思路在很长一段时间里都是很稳妥的方案，但是这个方案并不是唯一的方案。
+
+业界还有另外一种方案，叫做轻量级线程。这个方案在 Java 领域知名度并不高，但是在其他编程语言里却叫得很响，例如 Go 语言、Lua 语言里的协程，本质上就是一种轻量级的线程。轻量级的线程，创建的成本很低，基本上和创建一个普通对象的成本相似；并且创建的速度和内存占用相比操作系统线程至少有一个数量级的提升，所以基于轻量级线程实现 Thread-Per-Message 模式就完全没有问题了。
+
+Java 语言目前也已经意识到轻量级线程的重要性了，OpenJDK 有个 Loom 项目，就是要解决 Java 语言的轻量级线程问题，在这个项目中，轻量级线程被叫做 Fiber。下面我们就来看看基于 Fiber 如何实现 Thread-Per-Message 模式。
+
+### 用 Fiber 实现 Thread-Per-Message 模式
+
+Loom 项目在设计轻量级线程时，充分考量了当前 Java 线程的使用方式，采取的是尽量兼容的态度，所以使用上还是挺简单的。用 Fiber 实现 echo 服务的示例代码如下所示，对比 Thread 的实现，你会发现改动量非常小，只需要把 new Thread(()->{…}).start() 换成 Fiber.schedule(()->{}) 就可以了。
+
+```java
+
+final ServerSocketChannel ssc = 
+  ServerSocketChannel.open().bind(
+    new InetSocketAddress(8080));
+//处理请求
+try{
+  while (true) {
+    // 接收请求
+    final SocketChannel sc = 
+      serverSocketChannel.accept();
+    Fiber.schedule(()->{
+      try {
+        // 读Socket
+        ByteBuffer rb = ByteBuffer
+          .allocateDirect(1024);
+        sc.read(rb);
+        //模拟处理请求
+        LockSupport.parkNanos(2000*1000000);
+        // 写Socket
+        ByteBuffer wb = 
+          (ByteBuffer)rb.flip()
+        sc.write(wb);
+        // 关闭Socket
+        sc.close();
+      } catch(Exception e){
+        throw new UncheckedIOException(e);
+      }
+    });
+  }//while
+}finally{
+  ssc.close();
+}
+```
+
+那使用 Fiber 实现的 echo 服务是否能够达到预期的效果呢？我们可以在 Linux 环境下做一个简单的实验，步骤如下：
+
+1. 首先通过 ulimit -u 512 将用户能创建的最大进程数（包括线程）设置为 512；
+2. 启动 Fiber 实现的 echo 程序；
+3. 利用压测工具 ab 进行压测：ab -r -c 20000 -n 200000 http:// 测试机 IP 地址:8080/
+
+压测执行结果如下：
+
+```java
+
+Concurrency Level:      20000
+Time taken for tests:   67.718 seconds
+Complete requests:      200000
+Failed requests:        0
+Write errors:           0
+Non-2xx responses:      200000
+Total transferred:      16400000 bytes
+HTML transferred:       0 bytes
+Requests per second:    2953.41 [#/sec] (mean)
+Time per request:       6771.844 [ms] (mean)
+Time per request:       0.339 [ms] (mean, across all concurrent requests)
+Transfer rate:          236.50 [Kbytes/sec] received
+
+Connection Times (ms)
+              min  mean[+/-sd] median   max
+Connect:        0  557 3541.6      1   63127
+Processing:  2000 2010  31.8   2003    2615
+Waiting:     1986 2008  30.9   2002    2615
+Total:       2000 2567 3543.9   2004   65293
+```
+
+你会发现即便在 20000 并发下，该程序依然能够良好运行。同等条件下，Thread 实现的 echo 程序 512 并发都抗不过去，直接就 OOM 了。
+
+如果你通过 Linux 命令 top -Hp pid 查看 Fiber 实现的 echo 程序的进程信息，你可以看到该进程仅仅创建了 16（不同 CPU 核数结果会不同）个操作系统线程。
+
+![aebe9691be206fb88f45e4f763bcb7e9](img/aebe9691be206fb88f45e4f763bcb7e9.png)
+
+### 总结
+
+并发编程领域的分工问题，指的是如何高效地拆解任务并分配给线程。前面我们在并发工具类模块中已经介绍了不少解决分工问题的工具类，例如 Future、CompletableFuture 、CompletionService、Fork/Join 计算框架等，这些工具类都能很好地解决特定应用场景的问题，所以，这些工具类曾经是 Java 语言引以为傲的。不过这些工具类都继承了 Java 语言的老毛病：太复杂。
+
+如果你一直从事 Java 开发，估计你已经习以为常了，习惯性地认为这个复杂度是正常的。不过这个世界时刻都在变化，曾经正常的复杂度，现在看来也许就已经没有必要了，例如 Thread-Per-Message 模式如果使用线程池方案就会增加复杂度。
+
+Thread-Per-Message 模式在 Java 领域并不是那么知名，根本原因在于 Java 语言里的线程是一个重量级的对象，为每一个任务创建一个线程成本太高，尤其是在高并发领域，基本就不具备可行性。不过这个背景条件目前正在发生巨变，Java 语言未来一定会提供轻量级线程，这样基于轻量级线程实现 Thread-Per-Message 模式就是一个非常靠谱的选择。
+
+当然，对于一些并发度没那么高的异步场景，例如定时任务，采用 Thread-Per-Message 模式是完全没有问题的。实际工作中，我就见过完全基于 Thread-Per-Message 模式实现的分布式调度框架，这个框架为每个定时任务都分配了一个独立的线程。
+
+

note/java/concurrency/designpattern/WorkerThread.md

@@ -0,0 +1,141 @@
+## Worker Thread模式：如何避免重复创建线程？
+
+在上一篇文章中，我们介绍了一种最简单的分工模式——Thread-Per-Message 模式，对应到现实世界，其实就是委托代办。这种分工模式如果用 Java Thread 实现，频繁地创建、销毁线程非常影响性能，同时无限制地创建线程还可能导致 OOM，所以在 Java 领域使用场景就受限了。
+
+要想有效避免线程的频繁创建、销毁以及 OOM 问题，就不得不提今天我们要细聊的，也是 Java 领域使用最多的 Worker Thread 模式。
+
+Worker Thread 模式及其实现
+
+Worker Thread 模式可以类比现实世界里车间的工作模式：车间里的工人，有活儿了，大家一起干，没活儿了就聊聊天等着。你可以参考下面的示意图来理解，Worker Thread 模式中 Worker Thread 对应到现实世界里，其实指的就是车间里的工人。不过这里需要注意的是，车间里的工人数量往往是确定的。
+
+![9d0082376427a97644ad7219af6922c3](img/9d0082376427a97644ad7219af6922c3.png)
+
+那在编程领域该如何模拟车间的这种工作模式呢？或者说如何去实现 Worker Thread 模式呢？通过上面的图，你很容易就能想到用阻塞队列做任务池，然后创建固定数量的线程消费阻塞队列中的任务。其实你仔细想会发现，这个方案就是 Java 语言提供的线程池。
+
+线程池有很多优点，例如能够避免重复创建、销毁线程，同时能够限制创建线程的上限等等。学习完上一篇文章后你已经知道，用 Java 的 Thread 实现 Thread-Per-Message 模式难以应对高并发场景，原因就在于频繁创建、销毁 Java 线程的成本有点高，而且无限制地创建线程还可能导致应用 OOM。线程池，则恰好能解决这些问题。
+
+那我们还是以 echo 程序为例，看看如何用线程池来实现。
+
+下面的示例代码是用线程池实现的 echo 服务端，相比于 Thread-Per-Message 模式的实现，改动非常少，仅仅是创建了一个最多线程数为 500 的线程池 es，然后通过 es.execute() 方法将请求处理的任务提交给线程池处理。
+
+```java
+
+ExecutorService es = Executors
+  .newFixedThreadPool(500);
+final ServerSocketChannel ssc = 
+  ServerSocketChannel.open().bind(
+    new InetSocketAddress(8080));
+//处理请求    
+try {
+  while (true) {
+    // 接收请求
+    SocketChannel sc = ssc.accept();
+    // 将请求处理任务提交给线程池
+    es.execute(()->{
+      try {
+        // 读Socket
+        ByteBuffer rb = ByteBuffer
+          .allocateDirect(1024);
+        sc.read(rb);
+        //模拟处理请求
+        Thread.sleep(2000);
+        // 写Socket
+        ByteBuffer wb = 
+          (ByteBuffer)rb.flip();
+        sc.write(wb);
+        // 关闭Socket
+        sc.close();
+      }catch(Exception e){
+        throw new UncheckedIOException(e);
+      }
+    });
+  }
+} finally {
+  ssc.close();
+  es.shutdown();
+}   
+```
+
+### 正确地创建线程池
+
+Java 的线程池既能够避免无限制地创建线程导致 OOM，也能避免无限制地接收任务导致 OOM。只不过后者经常容易被我们忽略，例如在上面的实现中，就被我们忽略了。所以强烈建议你用创建有界的队列来接收任务。
+
+当请求量大于有界队列的容量时，就需要合理地拒绝请求。如何合理地拒绝呢？这需要你结合具体的业务场景来制定，即便线程池默认的拒绝策略能够满足你的需求，也同样建议你在创建线程池时，清晰地指明拒绝策略。
+
+同时，为了便于调试和诊断问题，我也强烈建议你在实际工作中给线程赋予一个业务相关的名字。
+
+综合以上这三点建议，echo 程序中创建线程可以使用下面的示例代码。
+
+```java
+
+ExecutorService es = new ThreadPoolExecutor(
+  50, 500,
+  60L, TimeUnit.SECONDS,
+  //注意要创建有界队列
+  new LinkedBlockingQueue<Runnable>(2000),
+  //建议根据业务需求实现ThreadFactory
+  r->{
+    return new Thread(r, "echo-"+ r.hashCode());
+  },
+  //建议根据业务需求实现RejectedExecutionHandler
+  new ThreadPoolExecutor.CallerRunsPolicy());
+```
+
+### 避免线程死锁
+
+使用线程池过程中，还要注意一种线程死锁的场景。如果提交到相同线程池的任务不是相互独立的，而是有依赖关系的，那么就有可能导致线程死锁。实际工作中，我就亲历过这种线程死锁的场景。具体现象是应用每运行一段时间偶尔就会处于无响应的状态，监控数据看上去一切都正常，但是实际上已经不能正常工作了。
+
+这个出问题的应用，相关的逻辑精简之后，如下图所示，该应用将一个大型的计算任务分成两个阶段，第一个阶段的任务会等待第二阶段的子任务完成。在这个应用里，每一个阶段都使用了线程池，而且两个阶段使用的还是同一个线程池。
+
+![](img/f807b0935133b315870d2d7db5477db8.png)
+
+我们可以用下面的示例代码来模拟该应用，如果你执行下面的这段代码，会发现它永远执行不到最后一行。执行过程中没有任何异常，但是应用已经停止响应了。
+
+```java
+
+//L1、L2阶段共用的线程池
+ExecutorService es = Executors.
+  newFixedThreadPool(2);
+//L1阶段的闭锁    
+CountDownLatch l1=new CountDownLatch(2);
+for (int i=0; i<2; i++){
+  System.out.println("L1");
+  //执行L1阶段任务
+  es.execute(()->{
+    //L2阶段的闭锁 
+    CountDownLatch l2=new CountDownLatch(2);
+    //执行L2阶段子任务
+    for (int j=0; j<2; j++){
+      es.execute(()->{
+        System.out.println("L2");
+        l2.countDown();
+      });
+    }
+    //等待L2阶段任务执行完
+    l2.await();
+    l1.countDown();
+  });
+}
+//等着L1阶段任务执行完
+l1.await();
+System.out.println("end");
+```
+当应用出现类似问题时，首选的诊断方法是查看线程栈。下图是上面示例代码停止响应后的线程栈，你会发现线程池中的两个线程全部都阻塞在 l2.await(); 这行代码上了，也就是说，线程池里所有的线程都在等待 L2 阶段的任务执行完，那 L2 阶段的子任务什么时候能够执行完呢？永远都没那一天了，为什么呢？因为线程池里的线程都阻塞了，没有空闲的线程执行 L2 阶段的任务了。
+
+![](img/43c663eedd5b0b75b6c3022e26eb1583.png)
+
+原因找到了，那如何解决就简单了，最简单粗暴的办法就是将线程池的最大线程数调大，如果能够确定任务的数量不是非常多的话，这个办法也是可行的，否则这个办法就行不通了。其实这种问题通用的解决方案是为不同的任务创建不同的线程池。对于上面的这个应用，L1 阶段的任务和 L2 阶段的任务如果各自都有自己的线程池，就不会出现这种问题了。
+
+最后再次强调一下：提交到相同线程池中的任务一定是相互独立的，否则就一定要慎重。
+
+### 总结
+
+我们曾经说过，解决并发编程里的分工问题，最好的办法是和现实世界做对比。对比现实世界构建编程领域的模型，能够让模型更容易理解。上一篇我们介绍的 Thread-Per-Message 模式，类似于现实世界里的委托他人办理，而今天介绍的 Worker Thread 模式则类似于车间里工人的工作模式。如果你在设计阶段，发现对业务模型建模之后，模型非常类似于车间的工作模式，那基本上就能确定可以在实现阶段采用 Worker Thread 模式来实现。
+
+Worker Thread 模式和 Thread-Per-Message 模式的区别有哪些呢？从现实世界的角度看，你委托代办人做事，往往是和代办人直接沟通的；对应到编程领域，其实现也是主线程直接创建了一个子线程，主子线程之间是可以直接通信的。而车间工人的工作方式则是完全围绕任务展开的，一个具体的任务被哪个工人执行，预先是无法知道的；对应到编程领域，则是主线程提交任务到线程池，但主线程并不关心任务被哪个线程执行。
+
+Worker Thread 模式能避免线程频繁创建、销毁的问题，而且能够限制线程的最大数量。Java 语言里可以直接使用线程池来实现 Worker Thread 模式，线程池是一个非常基础和优秀的工具类，甚至有些大厂的编码规范都不允许用 new Thread() 来创建线程的，必须使用线程池。
+
+不过使用线程池还是需要格外谨慎的，除了今天重点讲到的如何正确创建线程池、如何避免线程死锁问题，还需要注意前面我们曾经提到的 ThreadLocal 内存泄露问题。同时对于提交到线程池的任务，还要做好异常处理，避免异常的任务从眼前溜走，从业务的角度看，有时没有发现异常的任务后果往往都很严重。
+
+

note/java/concurrency/designpattern/img/token.drawio

@@ -0,0 +1 @@
+<mxGraphModel><root><mxCell id="0"/><mxCell id="1" parent="0"/></root></mxGraphModel>