你好，我是大彬。
不得不说，现在虽然大部分公司还是在使用的 JDK8，但是也有一些相对比较小的公司，会跟风，直接切换版本，毕竟这个项目切换版本，其实还是一个很大的问题，一般的大公司的话，可能并没有那么容易起的去切换版本，反而是小公司更容易去使用新技术，尽管可能有些问题解决不了，就像当初疯狂扩散的微服务，但是却不处理分布式所带来的事务问题一样，今天我们就来看看这个JDK11 给我们带来了哪些改变。
JDK11
关于 JDK11 的安装的话，了不起就压根不用说了，因为 JDK 的安装和配置，基本一样，但是从 JDK 10 开始，我装完之后，自动把 path 就给我配置了，所以，感觉更加的简单和方便了，我们看看 JDK11 中都增加加了哪些内容，不管实用不实用，我们知道有这个内容，那就给自己了印象，就没问题。
String
String 增加了一些 API，这些 API 也都是挺好用的内容，我们来看一下
代码语言：javascript复制 //判断字符串是否都是空
String str = "abc";
System.out.println(str.isBlank());
//去除字符串收尾空白
System.out.println(str.strip());
System.out.println(str.trim());
//去除首部的字符串空格
System.out.println(str.stripLeading());
//去除尾部的字符串空格
System.out.println(str.stripTrailing());
//复制字符串，复制多少次由repeat的参数决定
String str2 = "abc";
String repeat = str2.repeat(3);
System.out.println(repeat);
//统一字符串行数，没啥用
long count = str2.lines().count();
System.out.println(count);
至少目前来看，有几个方法是有点用的，但是也有没太大作用的，比如那个统一行数还有就是复制的，用的情况还真的不是太多的样子。
HttpClient
代码语言：javascript复制 //异步请求
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder(URI.create("http://baidu.com/")).build();
HttpResponse.BodyHandler<String> stringBodyHandler = HttpResponse.BodyHandlers.ofString();
CompletableFuture<HttpResponse<String>> future = client.sendAsync(request, stringBodyHandler);
HttpResponse<String> response = future.get();
// 返回结果
String body = response.body();
// 同步请求
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder(URI.create("http://baidu.com/")).build();
HttpResponse.BodyHandler<String> stringBodyHandler = HttpResponse.BodyHandlers.ofString();
HttpResponse<String> send = client.send(request, stringBodyHandler);
String body = send.body();
实际上在 JDK10 就已经出现了，只不过在 JDK11 中又做了优化，目前版本已经支持HTTP1.1、HTTP2、websocket等常用的基于http的协议，并支持了了同步、异步、响应式等交互方式。当前版本的实现还是比较简单，没有对于常用restful、content-type的封装支持。
删除 Java EE 和 CORBA 模块
由于EJB方案的繁琐和低效率一直以来备受诟病，而当EJB方案在与Spring分道扬镳之后，EJB方案全面衰落。这在如今我们在一些Spring书籍中还有对于一些EJB的描述。
EJB在我来看是希望能从标准方面制定一款大而全的产品，但实际上全面的覆盖带来的是，繁琐的规则，冗余的代码，难以遵守的设计规范。
因此从厂商来说，支持EJB就需要付出巨大的生产成本，更不要说正式投入生产环境。事实上Spring正式由于理念上与EJB的不同，采用了轻快小的方案，赢得了众多用户的支持。
并且从历史来看，复杂的设计意味着高昂的学习成本，生产成本，维护成本，Spring凭借此赢得了与EJB的竞争，但在Spring 3以后迅速的发展让Spring加入了众多的细化组件，此时Spring慢慢变得更为复杂。
在后续SpringBoot诞生，极大的简化了Spring的配置以及对于Spring众多组件的管理。这一点来看轻快小又是一次历史的选择了。
ZGC的改变
从JDK 8开始，JDK使用G1作为默认的垃圾回收器。G1可以说是GC的一个里程碑，G1之前的GC回收，还是基于固定的内存区域，而G1采用了一种“细粒度”的内存管理策略，不在固定的区分内存区域属于surviors、eden、old，而我们不需要再去对于年轻代使用一种回收策略，老年代使用一种回收策略，取而代之的是一种整体的内存回收策略。
这种回收策略在我们当下cpu、内存、服务规模都越来越大的情况下提供了更好的表现。 而这一代ZGC更是有了突破性的进步，SPECjbb 2015基准测试，在128G的大堆下
代码语言：javascript复制//数值越高越好
ZGC
max-jOPS: 100%
critical-jOPS: 76.1%
G1
max-jOPS: 91.2%
critical-jOPS: 54.7%
//数值越低越好
ZGC
avg: 1.091ms ( /-0.215ms)
95th percentile: 1.380ms
99th percentile: 1.512ms
99.9th percentile: 1.663ms
99.99th percentile: 1.681ms
max: 1.681ms
G1
avg: 156.806ms ( /-71.126ms)
95th percentile: 316.672ms
99th percentile: 428.095ms
99.9th percentile: 543.846ms
99.99th percentile: 543.846ms
max: 543.846ms
从原理上来理解，ZGC可以看做是G1之上更细粒度的内存管理策略。由于内存的不断分配回收会产生大量的内存碎片空间，因此需要整理策略防止内存空间碎片化，在整理期间需要将对于内存引用的线程逻辑暂停，这个过程被称为"Stop the world"。只有当整理完成后，线程逻辑才可以继续运行。一般而言，主要有如下几种方式优化"Stop the world"
- 使用多个线程同时回收（并行回收）
- 回收过程分为多次停顿（增量回收）
- 在程序运行期间回收，不需要停顿或只停顿很短时间（并发回收）
- 只回收内存而不整理内存
ZGC主要采用的是并发回收的策略，相较于G1 ZGC最主要的提升是使用Load Barrier技术实现，引用R大对于ZGC的评价.
对于Region的更细粒度控制，不同与G1的固定region，ZGC可以有多个size的RegionNuma架构的支持。
其实这个 ZGC 对我们开发来说是无感的操作，我们知道有这么回事就行。
关于 JDK11 的新特性，你还了解多少？
