OpenJDK

本文首发于：微信公众号「运维之美」，公众号 ID：Hi-Linux。 ​「运维之美」是一个有情怀、有态度，专注于 Linux 运维相关技术文章分享的公众号。公众号致力于为广大运维工作者分享各类技术文章和发布最前沿的科技信息。公众号的核心理念是：分享，我们认为只有分享才能使我们的团体更强大。如果你想第一时间获取最新技术文章，欢迎关注我们！ 公众号作者 Mike，一个月薪 3000 的杂工。从事 IT 相关工作 15+ 年，热衷于互联网技术领域，认同开源文化，对运维相关技术有自己独特的见解。很愿意将自己积累的经验、心得、技能与大家分享交流，篇篇干货不要错过哟。如果你想联系到我，可关注公众号获取相关信息。 这里将分享一些最新运维相关技术和业界资讯的精彩内容，每周五发布。 欢迎投稿或推荐你自己的项目，投稿邮箱: editor@hi-linux.com 。如果你对周刊有什么建议和意见，或者想与大家一起讨论技术问题，也可以戳「 这里 」加入技术交流群。 业界资讯 1、 中国设立互联网根服务器 近日，中国工信部官网一篇题为 “工业和信息化部关于同意中国互联网络信息中心设立域名根服务器（F、I、K、L根镜像服务器）及域名根服务器运行机构的批复” 的文章引起外界广泛关注。工信部当天的消息称，同意中国互联网络信息中心设立域名根服务器（F、I、K、L根镜像服务器）及成为域名根服务器运行机构，负责运行

2020年3月17日发布，Java正式发布了JDK 14 ，目前已经可以开放下载。在JDK 14中，共有16个新特性，本文主要来介绍其中的一个特性：JEP 359: Records 官方吐槽最为致命 早在2019年2月份，Java 语言架构师 Brian Goetz，曾经写过一篇文章(http://cr.openjdk.java.net/~briangoetz/amber/datum.html )，详尽的说明了并吐槽了Java语言，他和很多程序员一样抱怨“Java太啰嗦”或有太多的“繁文缛节”，他提到：开发人员想要创建 纯数据载体 类（plain data carriers）通常都必须编写大量低价值、重复的、容易出错的代码。如：构造函数、getter/setter、equals()、hashCode()以及toString()等。 以至于很多人选择使用IDE的功能来自动生成这些代码。还有一些开发会选择使用一些第三方类库，如Lombok等来生成这些方法，从而会导致了令人吃惊的表现（surprising behavior）和糟糕的可调试性（poor debuggability）。 那么，Brian Goetz 大神提到的纯数据载体到底指的是什么呢。他举了一个简单的例子： final class Point { public final int x; public final int y

2020年3月17日发布，Java正式发布了JDK 14 ，目前已经可以开放下载。在JDK 14中，共有16个新特性，本文主要来介绍其中的一个特性：JEP 359: Records 官方吐槽最为致命 早在2019年2月份，Java 语言架构师 Brian Goetz，曾经写过一篇文章( http://cr.openjdk.java.net/~briangoetz/amber/datum.html )，详尽的说明了并吐槽了Java语言，他和很多程序员一样抱怨“Java太啰嗦”或有太多的“繁文缛节”，他提到：开发人员想要创建 纯数据载体 类（plain data carriers）通常都必须编写大量低价值、重复的、容易出错的代码。如：构造函数、getter/setter、equals()、hashCode()以及toString()等。 以至于很多人选择使用IDE的功能来自动生成这些代码。还有一些开发会选择使用一些第三方类库，如Lombok等来生成这些方法，从而会导致了令人吃惊的表现（surprising behavior）和糟糕的可调试性（poor debuggability）。 那么，Brian Goetz 大神提到的纯数据载体到底指的是什么呢。他举了一个简单的例子： final class Point { public final int x; public final int

JDK 15已经在2020年9月15日发布！详情见 JDK 15 官方计划 。下面是对 JDK 15 所有新特性的详细解析！ 官方计划 2019/12/12 Rampdown Phase One (fork from main line) 2020/06/11 Rampdown Phase One (fork from main line) 2020/07/16 Rampdown Phase Two 2020/08/06 Initial Release Candidate 2020/08/20 Final Release Candidate 2020/09/15 General Availability 特性预览 339: 爱德华兹曲线数字签名算法（EdDSA） 360: Sealed Classes (Preview) 371: Hidden Classes 372: 移除 Nashorn JavaScript 引擎 373: 重新实现 DatagramSocket API 374: 禁用偏向锁 375: instanceof的模式匹配（Second Preview） 377: ZGC: 可扩展的低延迟垃圾收集器 378: 文本块 379: Shenandoah: 低暂停时间的垃圾收集器 381: 删除 Solaris 和 SPARC Ports 383: 外部存储器访问API

什么是ZGC > ZGC收集器(Z Garbage Collector)由Oracle公司研发.2018年提交了JEP 333将ZGC提交给了OpenJDK,推动进入OpenJDK11的发布清单中。ZGC收集器是基于 Region 内存布局，暂时不设分代,使用读屏障,着色指针和内存多重映射等技术来实现 并发的标记整理 算法,以低延迟为目标的一款收集器。 目标 > 在对吞吐量影响不大的情况下,对任意大小堆收集停顿时间都控制在10ms以内的低延迟。 ZGC堆内存布局 与G1一样,ZGC也采用基于 Region 的堆内存布局 ZGC的Region具有动态性 动态的创建和销毁 动态的 Region 容量大小 大小分类: 小型 Region (Small Region),固定大小2MB,存放小于256KB的小对象 中型 Region (Medium Region),固定大小32MB,存放大于256KB小于4MB的对象 大型 Region (Large Region),大小不固定,可以动态变化,但必须是2MB的整数倍,用于放大于4MB的大对象,每个大型 Region 只会放一个大对象,所以实际容量可能会小于中型 Region ,最小到4MB。大型 Region 在 ZGC 实现中不会被重分配,因为复制一个大对象代价太高。 着色指针 > 着色指针是一种直接将少量额外的信息存储在指针上的技术

> 本文的阅读有一定的门槛，请先了解 GC 的基本只知识。 现代垃圾收集器的演进大部分都是往减少停顿方向发展。 像 CMS 就是分离出一些阶段使得应用线程可以和垃圾回收线程并发，当然还有利用回收线程的并行来减少停顿的时间。 基本上 STW 阶段都是利用多线程并行来减少停顿时间，而并发阶段不会有太多的回收线程工作，这是为了不和应用线程争抢 CPU，反正都并发了慢就慢点（不过还是得考虑内存分配速率）。 而 G1 可以认为是打开了另一个方向的大门： 只回收部分垃圾来减少停顿时间 。 不过为了达到只回收部分 reigon，每个 region 都需要 RememberSet 来记录各 region 之间的引用。这个内存的开销其实还是挺大的，可能会占据整堆的20%或以上。 并且 G1 还有写屏障的开销，虽说用了 logging wtire barrier，但也还是有开销的。 当然 CMS 也用了写屏障，不过逻辑比较简单，啥都没判断就单纯的记录。 其实 G1 相对于 CMS 只有在大堆的场景下才有优势，CMS 比较伤的是 remark 阶段，如果堆太大需要扫描的东西太多。 而 G1 在大堆的时候可以选择部分收集，所以停顿时间有优势。 今天的主角 ZGC 和 G1 一样是基于 reigon 的， 几乎所有阶段都是并发的，整堆扫描，部分收集 。 而且 ZGC 还不分代，就是没分新生代和老年代。

1. getAndSet(int newValue) 它调用的是unsafe的getAndSetInt，如下List-1，不断的循环比较，而后设置结果。会阻塞，一直到设置完成。 List-1 public final int getAndSetInt(Object var1, long var2, int var4) { int var5; do { var5 = this.getIntVolatile(var1, var2); } while(!this.compareAndSwapInt(var1, var2, var5, var4)); return var5; } 2. compareAndSet(int expect, int update) 它调用的直接就是unsafe的compareAndSwapInt，这个方法不会阻塞调用，会立即返回，根据返回的boolean结果来判断是否成功 List-2 public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); } 3. weakCompareAndSet(int expect, int update)

使用场景一：一台服务上有多个应用，根据需要启动、关闭指定的一个或多个应用。 使用场景二：将开发环境制作成镜像，上线时直接使用镜像快速部署。 这里以场景一为例. 使用的操作系统使centos7.x 1、docker的安装启动关闭 systemctl stop docker.service systemctl start docker.service 2、安装运行docker的可视化管理工具portainer docker search portainer docker pull portainer/portainer docker volume create portainer_data // --privileged=true是授予挂载的权限 // -v前面的目录是宿主机目录，后面的目录是容器内目录 // -p 20000:9000 前面的端口号是外部访问使用的，后面的端口号为容器内部的. // portainer的默认端口为9000 docker run -d --name portainer --privileged=true -p 20000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer 访问http://ip

make JDK Version 1.0 1996-01-23 Oak(橡树) 初代版本，伟大的一个里程碑，但是是纯解释运行，使用外挂JIT，性能比较差，运行速度慢。 JDK Version 1.1 1997-02-19 JDBC(Java DataBase Connectivity); 支持内部类; RMI(Remote Method Invocation) ; 反射; Java Bean; JDK Version 1.2 1998-12-08 Playground(操场) 集合框架; JIT(Just In Time)编译器; 对打包的Java文件进行数字签名; JFC(Java Foundation Classes), 包括Swing 1.0, 拖放和Java2D类库; Java插件; JDBC中引入可滚动结果集,BLOB,CLOB,批量更新和用户自定义类型; Applet中添加声音支持. JDK Version 1.3 2000-05-08 Kestrel(红隼) Java Sound API; jar文件索引; 对Java的各个方面都做了大量优化和增强; JDK Version 1.4 2002-02-13 Merlin(隼) XML处理; Java打印服务; Logging API; Java Web Start; JDBC 3.0 API; 断言;

今天工作中，临时Fix一个bug，一看日志“java.lang.ClassCastException: null” 相当懵逼，没有详细堆栈信息，这咋整。虽然根据上下文可以推测问题代码的大致位置，但不敢拍板啊。只好google找一下，在Stackoverflow上果然有解决办法 【解决方法】 在java启动命令中添加“ -XX:-OmitStackTraceInFastThrow ” 即可输出详细堆栈信息——亲测可用。 【问题原因】 JVM（HotSpot JVM）进行了优化。当第一次发生异常（通常为NullPointerException）时，将打印完整的堆栈跟踪，并且JVM会记住堆栈跟踪（或者可能只是代码的位置）。 当该异常经常发生时，将不再打印堆栈跟踪，这既可以实现更好的性能， 【CoederBaby】 又不会使相同的堆栈跟踪充满日志 【进一步分析】 参看JVM源码（ 参见附录2 ），可见这个优化同时试用于以下异常： NullPointerException ArrayIndexOutOfBoundsException ClassCastException ArrayIndexOutOfBoundsException ArrayStoreException ArithmeticException 相关核心代码片段： // If this throw happens