java 协程 没有必要_为什么 Java 坚持多线程不选择协程？

前言：

这个是我一个粉丝问我的问题，一个刚从python转Java的粉丝朋友。特此拿出来分享一下。希望能对大家在这块有迷惑的有所帮助。以下是他的问题

面试时多线程是Java绕不去的坎，就有几个问题

1.为什么多线程在Java中这么重要？

2.据说多线程会出现难以排查的BUG，那么使用协程的话能否避免这些BUG呢？

3.go的协程是可以跑满整个核心的，但Java是不是除非从语言底层改造，否则做不到这一点？

4.Kotlin支持协程，是否用起来比多线程好呢？

5.所以，学好Java中的多线程是否还有必要呢？

答： 1.为什么多线程在Java中这么重要

多线程在哪里都很重要

2.据说多线程会出现难以排查的BUG，那么使用协程的话能否避免这些BUG呢

不能，其实协程需要学习的东西都更多。如果你学过C#的话，你去好好分析一个await函数里面的任意两行代码是不是执行在同一个线程里的，以及为什么，初学者都得头痛一阵子。然而你这个不知道的话，出了bug你连改都不会改。

用了协程你也不可避免会遇到数据共享的问题，要共享你要么atom要么interlocked要么上锁，这完全是多线程的内容。这个时候你甚至得去弄明白协程跟线程在实现的时候是如何对应的，不然就抓瞎。

3.go的协程是可以跑满整个核心的，但Java是不是除非从语言底层改造，否则做不到这一点

Java吧这个任务交给你了，你行程序就行，你不行程序就不行。

4.Kotlin支持协程，是否用起来比多线程好呢

参见2

所以，学好Java中的多线程是否还有必要呢

学什么语言都有必要学多线程，除了不让你开线程的。(不是黑)

结论与思考

先说结论：协程是非常值得学习的概念，它是多任务编程的未来。但是Java全力推进这个事情的动力并不大。

先返回到问题的本源。当我们希望引入协程，我们想解决什么问题。我想不外乎下面几点：

节省资源，轻量，具体就是：

节省内存，每个线程需要分配一段栈内存，以及内核里的一些资源

节省分配线程的开销(创建和销毁线程要各做一次syscall)

节省大量线程切换带来的开销

与NIO配合实现非阻塞的编程，提高系统的吞吐

使用起来更加舒服顺畅(async+await，跑起来是异步的，但写起来感觉上是同步的)

我们分开来讲下。

1. 先说内存。拿Java Web编程举例子，一个tomcat上的woker线程池的最大线程数一般会配置为50～500之间(目前springboot的默认值给的200)。也就是说同一时刻可以接受的请求最多也就是这么多。如果超过了最大值，请求直接打失败拒绝处理。假如每个线程给128KB，500个线程放一起的内存占用量大概是60+MB。如果真的有瓶颈，也许CPU，IO，带宽，DB的CPU等会有瓶颈，但这点内存量的增幅对于动辄数个GB的Java运行时进程来说似乎并不是什么大问题。

2. 换一个场景，比如IM服务器，需要同时处理大量空闲的链接(可能要几十万，上百万)。这时候用connection per thread就很不划算了。但是可以直接改用netty去处理这类问题。你可以理解为NIO + woker thread大致就是一套“协程”，只不过没有实现在语法层面，写起来不优雅而已。问题是，你的场景真的处理了并发几十万，上百万的连接吗？

3. 再说创建/销毁线程的开销。这个问题在Java里通过线程池得到了很好的解决。你会发现即便你用vert.x或者kotlin的协程，归根到底也是要靠线程池工作的。goroutine相当于设置一个全局的“线程池”，GOMAXPROCS就是线程池的最大数量；而Java可以自由设置多个不同的线程池(比如处理请求一套，异步任务另外一套等)。kotlin利用这个机制来构建多个不同的协程scope。这看起来似乎会更灵活一点。

4. 然后是线程的切换开销。线程的切换实际上只会发生在那些“活跃”的线程上。对于类似于Web的场景，大量的线程实际上因为IO(发请求/读DB)而挂起，根本不会参与OS的线程切换。现实当中一个最大200线程的服务器可能同一时刻的“活跃线程”总数只有数十而已。其开销没有想象的那么大。为了避免过大的线程切换开销，真正要防范的是同时有大量“活跃线程”。这个事情我自己上学的时候干过，当时是写了一个网络模拟器。每一个节点，每一个链路都由一个线程实现。模拟跑起来后，同时的活跃线程上千。当时整个机器瞬间卡死，直到kill掉这个程序。

5. 此外说说与NIO的配合。在Java这个生态里Java NIO/Netty/Vert.X/rxJava/Akka可以任意选择。一般来讲，Netty可以解决绝大部分因为IO的等待造成资源浪费的问题。Vert.X/rxJava。可以让程序写的更加“优雅”一点(见仁见智)。Akka就是Java世界里对“原教旨OO“的实现，很有特色。的确，用NIO + completedFuture/handler/lambda不如async+await写起来舒服，但起码是可以干活的。

6. 如果真的要较真Java的NIO用于业务的问题，其核心痛点应该是JDBC。这是个诞生了几十年的，必须使用Blocking IO的DB交互协议。其上承载了Java庞大的生态和业务逻辑。Java要改自己的编程方式，必须得重新设计和实现JDBC，就像https://github.com/vert-x3/vertx-mysql-postgresql-client 那样做。问题是，社区里这种“异步JDBC”还没有支持oracle、sql server等传统DB。对mysql和postgres的支持还需要继续趟坑～

7. 如果认真阅读上面这些需要“协程”解决的问题，就会发现基本上都可以以各种方式解决。觉得线程耗资源，可以控制线程总数，可以减少线程stack的大小，可以用线程池配置max和min idle等等。想要go的channel，可以上disruptor。可以说，Java这个生态里尽管没有“协程”这个第一级别的概念，但是要解决问题的工具并不缺。

8. Java仅仅是没有解决”协程“在Java中的定义，以及“写得优雅“这个问题。从工程角度，“写得优雅”的优势并没有很多追新的人想象的那么关键。C#也并非因为有了async await就抢了Java的市场分毫。而反过来，如果java社区全力推进这个事情，Java历史上的生态的积累却因为协程的出现而进行大换血。想像一下如果没有thread，也没有ThreadLocal，@Transactional不起作用了，又没有等价的工具，是不是很郁闷？这么看来怎么着都不是个划算的事情。我想Oracle对此并不会有太大兴趣。OpenJDK的loom能不能成，如果真的release多少Java程序员愿意使用，师母已呆。据我所知在9012年的今天，还有大量的Java6程序员。

9. 其他新的语言历史包袱少，比较容易重新思考“什么是现代的multi-task编程的方式“这个大主题。kotlin的协程、go的goroutine、javascript的async await、python的asyncio、swift的GCD都给了各自的答案。如果真的想入坑Java这个体系的“协程”，就从kotlin开始吧，毕竟可以混合编程。

最后说一句，多线程容易出bug主要因为：

“抢占“式的线程切换 —— 你无法确定两个线程访问数据的顺序，一切都很随机

“同步“不可组装 —— 同步的代码组装起来也不同步，必须加个更大的同步块

协程能不能避免容易出bug的缺陷，主要看能不能避免上面两个问题。如果协程底层用的还是线程池，两个协程还是通过共享内存通讯，那么多线程该出什么bug，多协程照样出。javascript里不出这种bug是因为其用户线程就一个，不会出现线程切换，也不用同步；go是建议用channel做goroutine的通讯。如果go routine不用channel，而是用共享变量，并且没有用Sync包控制一下，还是会出bug。