@mingzizhi JDK 从 Sun 时代就一直存在商业版本,当时叫做 Java for Business, 如果没有购买这个授权的话,我们最高就只能从官方网站上下载到浑身漏洞和 Bug 的 Java SE 5 Update 22 版本(2009 年),而 jdk1.5 的商业版本延伸到了 2015 年并且最后一个补丁包是 Java SE 5 Update 85.补丁包从 22 到 85 之间修复了无数个 Bug 和安全漏洞.
同样, JDK 6 的最后一个公开提供的补丁包是 45, 但是购买了 Oracle 的 JavaSE 订阅服务的企业用户直到今天仍然在享受着支持服务,最新的补丁包已经到了 201 了,补丁包从 45 到 201 间存在多少 Bug 和安全漏洞完全是无法想象的.

另外,Oracle 宣布的 JDK8 生命周期只是 Oracle 公开版本的服务结束期,付费订阅是不受影响的, 同时, Oracle 公开版本生命周期结束后,并不代表其他兼容的 JDK8 生命周期也结束,例如 RedHat 自行维护的 OpenJDK8 分支, IBM J9 等.

最简单的做法可能就是通过这个服务的 WSDL 用 CXF,Axis2 这些框架提供的命令行工具直接生成客户端相关代码

翻翻开源项目的源代码，spring, hibernate 这些,注释通常都比代码行数多，尤其是 public 的 API,

加法: 飞行记录器, ZGC 垃圾收集器和新的 HTTP Client API 看起来都还不错,TLS 1.3 的支持也是必须的.
减法: Nashorn, WebStart/Plugin/Applet, Derby, CORBA, JavaFX, JAF, JAXB, JAX-WS, Common Annotations 等.

新增的都是有用的, 减去的基本都是 1.过时的, 2.JavaEE 相关的(Oracle 不再维护 JavaEE,已移交给 Eclipse 基金会)

说的是用来贷款时的额度，跟公积金提取是两码事

有一种租赁叫做笔记本电脑租赁，员工自带笔记本电脑上班公司每月支付 300 租赁费......

websphere 控制台里面翻译成了概要，所以我们经常用开发概要，生产概要，测试概要等称呼某个 profile

百度云 mac 版客户端确实残废，一直都是这个样子的

虽然是二手的，但起码不是假的，总比某宝某猫全假货强

N+1 赔偿，每个人赔个几十万，值！

@esolve 基本都还在用 CMS，一方面是熟悉这个，另一方面我们的业务对停顿时间敏感，吞吐量的要求不是非常苛刻吞吐量需求只能排在第二位所以对于 G1 还在观望中

@esolve 一般都是先根据硬件情况大致测算出不同堆内存的 Full GC 的停顿时间，一般应用是不允许 GC 停顿超过 1.5 秒,否则就会影响上层业务，在 1.5 秒这个范畴内去设置合理的堆内存，一般硬件上也就三四个 G 的样子， 解决 STW 的问题主要还是靠单机多进程集群的方式，比如你有 32G 的内存可以分配给 JVM 进程，如果你把这些内存一次性分配给一个 JVM 进程，那么一旦产生 FULL GC,应用可能直接停顿半分钟以上甚至一分钟，这绝对是无法接受的，所以通常应该多起几个 JVM 进程，每个进程发生 FULL GC 的时候都要控制在 1.5 秒这个范畴内，这样才不会对上层业务产生影响，开 8 个 JVM 进程每个 4G 内存 1.5 秒 FULL GC 时间明显要比单个进程 32G 内存 1 分钟 FULL GC 好的多，我说的这些都是针对停顿时间敏感的业务比如高并发的 web 应用和 API 服务，如果对停顿时间不敏感也可以只开一个进程，比如后台跑算法啊批处理作业啊爬虫啊什么的就无所谓停顿多长时间了，因为即便是 FULL GC 一次十分钟，我们也是可以接受的

我想问一下，你们开这么大的堆内存，生产环境上有没有实际监控过一次 FULL GC 需要花费的时间呢，恐怕都得以分钟来计吧，难道你们的业务都不需要考虑 STW 的问题？还是除了常用的 CMS 和 G1 收集器外，你们手里还有更吊的垃圾收集器？