并发编程的核心是什么？
同步
互斥
分工
并发编程解决分工问题有哪些设计模式？
Thread-Per-Message模式
Worker Thread模式
生产者-消费者模式
…
简单说说Thread-Per-Message模式
将事情委托他人代办，有个好处，就是可以专心做自己事了。
编程也是这样，比如写一个HTTP Server，很显然只能在主线程中接收请求，而不能处理HTTP请求，因为若在主线程中处理HTTP请求，则同一时间只能处理一个请求，太慢了！这时就可以采取委托的思路，创建一个子线程，委托子线程去处理HTTP请求。
这种骚操作，在并发领域就是Thread-Per-Message模式（后文简称为 TPM）：为每个任务分配一个独立线程。这也是最简单的一种分工方案。
Java 线程实现TPM
TPM最经典的应用场景就是网络编程的服务端实现。
服务端为每个客户端请求创建一个独立线程，当线程处理完请求后，自动销毁，这是最简单的并发处理网络请求的方法。
比如echo程序的服务端
但该实现不可能在实际生产使用，因为Java线程实在是个重量级对象：
创建线程比较耗时
线程占用的内存也较大
所以，为每个请求创建一个新的线程并不适合高并发。
难道TPM只是空想国？如果换一种实现，估计你会想到线程池，但引入线程池会增加复杂度。
语言、工具、框架本应是提供更高性能实现方案的，而不是用来否定方案的，TPM作为一种最简单的分工方案，Java语言支持不了，显然是Java语言本身设计问题。
Java线程和os线程一一对应，该做法本质上是将Java线程的调度权完全委托给os，而os在这方面非常成熟，所以这种做法的好处是稳定、可靠，但是也继承了os线程的缺点：创建成本高。为了解决这个缺点，J.U.C提供了线程池等工具类。但该方案并非唯一方案。
业界普遍使用的还有：
轻量级线程
在Java领域知名度不高，但和Go里的协程，本质都是一种轻量级线程。其创建成本很低，和创建一个普通对象类似；并且创建速度和内存占用相比os线程至少有一个数量级提升，所以基于轻量级线程实现TPM就完全没有问题。
Java也意识到轻量级线程的意义，OpenJDK的Loom项目就是要解决Java语言的轻量级线程问题。Loom 中的轻量级线程称为Fiber。
使用Fiber实现TPM。
Loom在设计轻量级线程时，也充分参考了当前Java线程的使用方式，所以学习成本还是很低的。只需将new Thread(()->{…}).start()换成 Fiber.schedule(()->{})。
在 Java 高并发领域，虽然不具备可行性，不过对一些并发度没那么高的异步场景，例如定时任务，采用 TPM完全没问题。
