Java与GO语言对比分析

你是不是总听到go与java种种对比，其中在高并发的服务器端应用场景会有人推荐你使用go而不是 java。
那我们就从两者运行原理和基本并发设计来对比分析，看看到底怎么回事。

java 中 jdk 已经帮我们屏蔽操作系统区别。
只要我们下载并配置好 jdk，我们就能执行java 文件了。

在这里插入图片描述

go tool 中使用 go build 就能将 go 代码编译生成对应操作系统的可执行文件，可以直接运行。

在这里插入图片描述

我们会在不同操作系统下，去下载适配对应操作系统的 jdk。实现我们一次编写，任意运行在各个操作系统的 JVM上。

在这里插入图片描述

编写go 代码后，我们利用 go tools 中编译器指定要执行的操作系统进行 build。生成一个平台相关的可执行文件（在 Windows 上是 .exe 文件，在 Linux 或 macOS 上通常是没有扩展名的二进制文件）

在这里插入图片描述

线程的生命周期
假设客户端每提交一个任务，需要单独 java 线程处理，会有如下流程。

在这里插入图片描述

其实不难发现，java 线程模型其实比较偷懒···。对的，它基本没干啥，直接和一个操作系统的线程绑定（1 对 1），这样java 就不用考虑线程调度管理了，操作系统会调度运行线程。

池化操作
当然作为一名优秀的java开发，如果按照上述那样使用线程，当有客户端足够多，也就是所谓高并发情况下，java 线程模型就会导致服务崩溃，是的你没有听错，崩溃宕机。
所以优秀 java开发常常不会‘裸’使用thread，会将使用线程池技术将线程进行池化保存，让线程能够复用。

池化的初始化流程
1.java中初始化4个Thread对象（用户态）
2.操作系统内核中初始化4个Thread（内核态）
3.客户端提交线程任务到任务队列
4.线程池中线程从任务队列中消费任务（内核Thread-就绪态）
5.由操作系统调度对应内核线程

池化后流程：
1.客户端提交线程任务到任务队列
2.线程池中线程从任务队列中消费任务（内核Thread-就绪态）
2.由操作系统调度对应内核线程

ps：至于线程池详细学习，这里就不介绍了。

在这里插入图片描述

来吧让我们了解了解go的并发模型（MPG）吧。

ps:这里参考《Go 并发编程实战》，想要详细了解MPG实现细节可以看这本书。

在这里插入图片描述

G：goroutine缩写。每一个并发执行的活动称为G
P：processor的缩写。一个P代表执行一个Go代码片段所必需的资源（或称“上下文环境”）
M：machine的缩写。一个M代表一个内核线程

运行流程
1.go 接受并发任务封装 G
2.寻找合适p并放入 p 中（p 中存在列表保存待执行 G）
3.p 与某个 M （空闲或新创建）进行关联
4.创建一个内核线程与 M 对应
5.由操作系统调度对应内核线程

我本身java开发，当我了解 MPG 模型我就感觉，其实和 java 线程池执行并行任务大差不差。都是池化固定几个内核线程并发执行应用层面提交的任务。就是达到了线程复用，省去频繁创建销毁的操作。

那是不是 java 线程池可以和 MPG 并发模型相媲美呢？

随着我深入了解发现并不是这样的。仔细想一下 java 线程池怎么使用，是在一个业务中我们需要频繁的创建和销毁线程，然后我们创建一个线程池给这个业务使用。

是的，这个线程池这是这个业务局部使用的。但是 java 其他业务如果没使用线程池直接使用线程并发，或者thread-per-request style（每个请求启动一个线程）都会造成java 应用中会存在很多没有池化线程。

相比于 java，go 则是全局模型，也就是说整个 go 应用的 M 都是复用的，创建和销毁频率会非常小。而且在理想情况，能实现一个核心对应一个线程，无需资源竞争。另外就是，在并发业务编写场景下，go 是如此丝滑且高效····

java 线程模型虽然笨重但也有自己优势。

复杂的线程上下文代表功能很多，例如 threadLocal，让我们更加便捷实现一些业务功能（用户信息，鉴权相关功能都能利用到）。
此外，我对比的是过时的 java8。在 java 新版本中也已经实现了类似goroutines的用户态线程，java称作virtual threads有兴趣的可以看看，下篇就分享这个。