Thread-Pre-Message设计模式

Posted 2021-06-11 做时间的好朋友

1.Thread-Pre-Message 设计模式

简单来说，就是为每个任务分配一个独立的线程，最简单的分工方法

2.并发领域3个核心问题

分工，同步，互斥

同步，互斥源自微观，分工来自宏观

Thread-Pre-Message其实就是一种分工模式

3.映射现实世界

教育小朋友搞不定，委托学校老师
忙着写Bug,没时间买别墅,委托房产中介

4.HttpServer

自编HttpServer，主线程中接受请求，不能处理http请求，如果处理，就同时只能处理一个请求，太慢了。代办思路，创建子线程，委托子线程去处理http请求

5.这种委托他人办理的方式，就是Thread-Pre-Message设计模式

6.伪代码

final ServerSocketChannel  = 
  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();
}   

客户端发送什么，服务端返回什么
但是上面伪代码不具有可行性，是因为java语言的问题，java中的线程是重量级的线程，创建成本高，而且创建线程比较耗时，而且占用内存也大。为每个请求创建一个新的线程也不适合高并发场景。

7.线程池优化思路

引入线程池会增加复杂度

8.java中的线程

java中的线程和操作系统是一一对应的，这种做法本质上是将java线程的调度权交给操作系统，操作系统在这方面比较成熟，好处是稳定，可靠。但是也继承了系统线程的缺点：创建成本高。
所以java并发包提供了线程池工具类。这个思路在很长的时间内都是很稳妥的方案。

9.轻量级线程-协程

GO语言，lua，本质就是轻量级线程，创建成本低，基本与创建对象成本相似。创建速度于内存占用相比较操作系统的线程来说有一个数量级提升，基于协程实现Thread-Per-Message 模式完全没问题。一个请求一个线程。频繁创建协程，销毁协程序，几万个协程都可以接受。

10.java的协程方案，Fiber（暂未商用，稳可靠性，稳定性还有待更多实践验证）

伪代码

final ServerSocketChannel ssc = 
  ServerSocketChannel.open().bind(
    new InetSocketAddress(8080));
//处理请求
try{
  while (true) {
    // 接收请求
    final SocketChannel sc = 
      ssc.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();
}

ulimit -u 512，修改用户能创建的最大进程数（包括线程）设置为512
使用ab压测，测试
ab -r -c 20000 -n 200000
-r 出错继续
-c 并发2万
-n 总共20万个请求

压测结果:

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

程序依然良好运行，同样使用new Thread（）实现，512并发扛不住，就直接OOM了

11.并发编程分工问题

工具类中有

Future,CompletableFuture,CompletionService,Fork/Join

12.不需要并发读那么高的场景可以使用Thread-Pre-Message

例如定时任务

12.思考

Thread-Per-Message 为每个人物创建一个线程，高并发中，很容易OOM，那么怎么能快速解决？

(1)临时解决，修改jvm内存配置，增大jvm新生代大小
(2)长期解决，引入NIO，使用netty
(3)引入线程池控制,在请求端添加限流模块semaphore，自我保护
(4)tomcat用的线程池的思路解决高并发问题
(5)java中的线程是内核空间，协程是用户空间