jdk8和jdk11区别

大家好,我是孙子烧烤,近期有同学私信我,说JDK8与JDK11的区别。

因为大家部署项目通常使用JDK8,现在JDK11已经推出,我这里简单介绍一下JDK11的新特性。

JDK 11主要特性一览

  确定的新特性包括以下17个

  这一次的JDK升级对于java这个语言来说是一次新生。这是JDK第一次在一年内进行两次大版本的升级,原本在JDK9宣布JAVA要加速JDK升级每年发布一个版本时,笔者还是存在一些疑虑的,由于Java现在已经是世界上使用范围最广的语言之一,贸然的引入新特性造成的影响太大。但从该版本来看JDK确实成功的完成了既定目标,并且已经宣布JDK12会在19年九月发布正式版。对于Java开发者来说,一方面是新特性带来的便捷而另一方面是要努力学习了~

  ZGC是这次JDK的最大的亮点,JVM GC 子在大内存服务中的性能有了一个质的改变,直接将AZul的商用JVM C4优势拉近了一个身位。相较G1,ZGC最大的不同是使用了Load Barrier及颜色指针技术。虽然目前ZGC只是实验版本,但可以预见不远的将来ZGC会覆盖大多数的服务器。

  James Gosling曾表明,如果可以重新设计java,他希望是scala的样子。
从JDK 11来看,靠近scala确实做到了。从JDK 8的lambda表达式到现在的 “嵌套类可见性支持/用于 Lambda 参数的局部变量语法/Launch Single-File Source-Code Programs”,Java都在向scala 学习。前两天在跟朋友开玩笑,如果java中能够支持“隐式转换”,那spring、guice这类注入框架都得重写了,java也能改名叫jcala了。Java由于历史遗留问题,在函数式计算支持方面还是存在很大的问题,没有办法像scala可以更好的支持函数式计算。例如在scala中,adt类型都已经划分的非常清楚,有mutable、immutable、parallel、concurrent等类型的支持,而java中还需要引入额外的对象来辅助实现函数式计算。从长远来看虽然java可以逐渐向scala靠拢,但在函数式计算方面java的支持还会和scala有比较大的差距。如果对于大数据、函数式计算的同学推荐了解一下scala。

  以下是对JDK 11的主要特性的介绍和分析。

ZGC

  从JDK 8开始,JDK使用G1作为默认的垃圾回收器。G1可以说是GC的一个里程碑,G1之前的GC回收,还是基于固定的内存区域,而G1采用了一种“细粒度”的内存管理策略,不在固定的区分内存区域属于surviors、eden、old,而我们不需要再去对于年轻代使用一种回收策略,老年代使用一种回收策略,取而代之的是一种整体的内存回收策略。这种回收策略在我们当下cpu、内存、服务规模都越来越大的情况下提供了更好的表现。
  而这一代ZGC更是有了突破性的进步,SPECjbb 2015基准测试,在128G的大堆下

  //数值越高越好
  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的评价

与标记对象的传统算法相比,ZGC在指针上做标记,在访问指针时加入Load Barrier(读屏障),比如当对象正被GC移动,指针上的颜色就会不对,这个屏障就会先把指针更新为有效地址再返回,也就是,永远只有单个对象读取时有概率被减速,而不存在为了保持应用与GC一致而粗暴整体的Stop The World。

此外还有

  • 对于Region的更细粒度控制,不同与G1的固定region,ZGC可以有多个size的Region
  • Numa架构的支持

延伸阅读
ZGC wiki
A FIRST LOOK INTO ZGC
Java程序员的荣光,听R大论JDK11的ZGC
AZul 论文

嵌套类可见性支持

  嵌套类可见性支持,这里主要增加了对于嵌套类private的支持。

  class A {
    public void f1() {
    B b = new B();
      // System.out.println(b.s) //jdk 10后不能通过编译
     // System.out.println(b.f2()) //jdk 10后不能通过编译
    }
    class B {
    private String s = "b";
      private void f2() {
        System.out.println("f2");
      }
    }
  }

用于 Lambda 参数的局部变量语法

  看到这两个特性的时候,感觉到java开始向scala开始靠拢了。

  用于 Lambda 参数的局部变量语法简单来说就是支持的类型推导

  var x = new A();  for (var x : xs) { ... }  try (var x = ...) { ... } catch ...

  类型推导这几年在python, scala中非常火爆,虽然实现不难,但java迟迟没有对于类型推导的支持。如今java终于支持类型推导了。省去了对于类型的直接声明,并且在函数式计算中,类型推导也能很大程度上省略一些冗余的代码。

Launch Single-File Source-Code Programs

  Launch Single-File Source-Code Programs
  这个说起来比较简单,启动单一文件的源代码程序这块对于脚本开发会有一些帮助。目前来看java面向对象的语法导致的问题是代码的冗余,实际上脚本开发上面向过程编程。并且JDK目前没有一个比较好的JConsole的支持,三方库依赖实现复杂,因此这方面来说pyton对于脚本开发更有优势。个人不看好未来JDK对脚本的支持。

HTTP Client

  对于Http Client 这个功能来说,我认为Jdk对于这个场景支持还是比较迟了。以致于这样一个常用的场景,我们不得不引入三方apache commons 的HTTPClient或者OKHTTP等三方库。从目前来看,jdk10对于这块的功能支持还是不错的,目前版本已经支持HTTP1.1、HTTP2、websocket等常用的基于http的协议,并支持了了同步、异步、响应式等交互方式。当前版本的实现还是比较简单,没有对于常用restful、content-type的封装支持。
个人猜测,很可能这个场景的支持是为了Launch Single-File Source-Code Programs脚本开发支持的,哈哈~~

动态文件常量/低开销的 Heap Profiling

  动态文件常量主要增加了 CONSTANT_Dynamic 这种常量池形式,主要用于丰富常量池API相关接口,并优化常量生成策略。

  低开销的 Heap Profiling,提供一种低开销的获取Java 堆对象使用信息的JVM接口。之前的堆都是基于事件进行callback,这个接口的提供可以更好的实现对于jvm内存的分析。
  接口定义如下

  jvmtiError  SetHeapSamplingInterval(jvmtiEnv* env, jint sampling_interval)  //使用示例
  jvmti->SetEventNotificationMode(jvmti, JVMTI_ENABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)

TLS 1.3支持

  TLS 主要是对于https的新标准的一些支持,主要包括

  • Protocol version negotiation
  • TLS 1.3 full handshake
  • TLS 1.3 session resumption
  • TLS 1.3 key and iv update
  • TLS 1.3 updated OCSP stapling
  • TLS 1.3 backward compatibility mode
  • TLS 1.3 required extensions and algorithms
  • RSASSA-PSS signature algorithms (8146293)

JDK8的新特性:

一、Lambda表达式

1.1 函数式编程

百科介绍:http://baike.baidu.com/link?url=LL9X3-SoS4XJGgdzrXvURuKEGm6ad5zY1NLDxDygjTaSRnEZ0Bp3wqX0QgkB7fjPwMSQS1tLfqdRMKUhNti7MH7DEK7JQ_lXcs9k6LXHT1A9dSJW8uwJMONJcvXY53h6myMCkqjL3IqW8QRgbdNDl_
函数编程非常关键的几个特性如下:
(1)闭包与高阶函数
函数编程支持函数作为第一类对象,有时称为 闭包或者 仿函数(functor)对象。实质上,闭包是起函数的作用并可以像对象一样操作的对象。
与此类似,FP 语言支持 高阶函数。高阶函数可以用另一个函数(间接地,用一个表达式) 作为其输入参数,在某些情况下,它甚至返回一个函数作为其输出参数。这两种结构结合在一起使得可以用优雅的方式进行模块化编程,这是使用 FP 的最大好处。
(2)惰性计算
在惰性计算中,表达式不是在绑定到变量时立即计算,而是在求值程序需要产生表达式的值时进行计算。延迟的计算使您可以编写可能潜在地生成无穷输出的函数。因为不会计算多于程序的其余部分所需要的值,所以不需要担心由无穷计算所导致的 out-of-memory 错误。
(3)没有“副作用”
所谓”副作用”(side effect),指的是函数内部与外部互动(最典型的情况,就是修改全局变量的值),产生运算以外的其他结果。函数式编程强调没有”副作用”,意味着函数要保持独立,所有功能就是返回一个新的值,没有其他行为,尤其是不得修改外部变量的值。
综上所述,函数式编程可以简言之是: 使用不可变值和函数, 函数对一个值进行处理, 映射成另一个值。这个值在面向对象语言中可以理解为对象,另外这个值还可以作为函数的输入。

1.2 Lambda表达式

官方教程地址

1.2.1 语法

完整的Lambda表达式由三部分组成:参数列表、箭头、声明语句;

(Type1 param1, Type2 param2, ..., TypeN paramN) -> {  statment1;  statment2;  //.............  return statmentM;}

1. 绝大多数情况,编译器都可以从上下文环境中推断出lambda表达式的参数类型,所以参数可以省略:

(param1,param2, ..., paramN) -> {  statment1;  statment2;  //.............  return statmentM;}

2、 当lambda表达式的参数个数只有一个,可以省略小括号:

param1 -> {  statment1;  statment2;  //.............  return statmentM;}

3、 当lambda表达式只包含一条语句时,可以省略大括号、return和语句结尾的分号:

param1 -> statment

这个时候JVM会自动计算表达式值并返回,另外这种形式还有一种更简写法,方法引用写法,具体可以看下面的方法引用的部分。

1.2.2 函数接口

函数接口是只有一个抽象方法的接口, 用作 Lambda 表达式的返回类型。
接口包路径为java.lang.function,然后接口类上面都有@FunctionalInterface这个注解。下面列举几个较常见的接口类。

图片[1]-jdk8和jdk11区别-京讯网络

Paste_Image.png

这些函数接口在使用Lambda表达式时做为返回类型,JDK定义了很多现在的函数接口,实际自己也可以定义接口去做为表达式的返回,只是大多数情况下JDK定义的直接拿来就可以用了。而且这些接口在JDK8集合类使用流操作时大量被使用。

1.2.3 类型检查、类型推断

Java编译器根据 Lambda 表达式上下文信息就能推断出参数的正确类型。 程序依然要经过类型检查来保证运行的安全性, 但不用再显式声明类型罢了。 这就是所谓的类型推断。Lambda 表达式中的类型推断, 实际上是 Java 7 就引入的目标类型推断的扩展。

图片[2]-jdk8和jdk11区别-京讯网络

Image.png

有时候显式写出类型更易读,有时候去掉它们更易读。没有什么法则说哪种更好;对于如何让代码更易读,程序员必须做出自己的选择。

1.2.4 局部变量限制

Lambda表达式也允许使用自由变量(不是参数,而是在外层作用域中定义的变量),就像匿名类一样。 它们被称作捕获Lambda。 Lambda可以没有限制地捕获(也就是在其主体中引用)实例变量和静态变量。但局部变量必须显式声明为final,或事实上是final。
为什么局部变量有这些限制?
(1)实例变量和局部变量背后的实现有一个关键不同。实例变量都存储在堆中,而局部变量则保存在栈上。如果Lambda可以直接访问局部变量,而且Lambda是在一个线程中使用的,则使用Lambda的线程,可能会在分配该变量的线程将这个变量收回之后,去访问该变量。因此, Java在访问自由局部变量时,实际上是在访问它的副本,而不是访问原始变量。如果局部变量仅仅赋值一次那就没有什么区别了——因此就有了这个限制。
(2)这一限制不鼓励你使用改变外部变量的典型命令式编程模式。

1.2.5 使用示例

List<Integer> list = Arrays.asList(1,2,3,4,5,6,7,8,9,10);
long num = list.stream().filter( a -> a > 4 ).count();
System.out.println(num);

上面这段是统计list中大于4的值的个数,使用的lambda表达式为a->
a> 4
,这里参数a没有定义类型,会自动判断为Integer类型,而这个表达式的值会自动转化成函数接口Predicate对应的对象(filter方法定义的输入参数类型),至于stream及相关的操作则是下面要说的流操作。它们经常一起配合进行一起数据处理。

二、流

2.1 流介绍

流是Java API的新成员,它允许你以声明性方式处理数据集合(通过查询语句来表达,而不是临时编写一个实现)。就现在来说,你可以把它们看成遍历数据集的高级迭代器。此外,流还可以透明地并行处理,你无需写任何多线程代码了!

2.2 使用流

类别方法名方法签名作用
筛选切片filterStream<T> filter(Predicate<? super T> predicate)过滤操作,根据Predicate判断结果保留为真的数据,返回结果仍然是流
 distinctStream<T> distinct()去重操作,筛选出不重复的结果,返回结果仍然是流
    
 limitStream<T> limit(long maxSize)截取限制操作,只取前 maxSize条数据,返回结果仍然是流
    
 skipStream<T> skip(long n)跳过操作,跳过n条数据,取后面的数据,返回结果仍然是流
    
映射map<R> Stream<R> map(Function<? super T, ? extends R> mapper)转化操作,根据参数T,转化成R类型,返回结果仍然是流
 flatMap<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper)转化操作,根据参数T,转化成R类型流,这里会生成多个R类型流,返回结果仍然是流
    
匹配anyMatchboolean anyMatch(Predicate<? super T> predicate)判断是否有一条匹配,根据Predicate判断结果中是否有一条匹配成功
 allMatchboolean allMatch(Predicate<? super T> predicate)判断是否全都匹配,根据Predicate判断结果中是否全部匹配成功
    
 noneMatchboolean noneMatch(Predicate<? super T> predicate)判断是否一条都不匹配,根据Predicate判断结果中是否所有的都不匹配
    
查找findAnyOptional<T> findAny()查找操作, 查询当前流中的任意元素并返回Optional
 findFirstOptional<T> findFirst()查找操作, 查询当前流中的第一个元素并返回Optional
    
归约reduceT reduce(T identity, BinaryOperator<T> accumulator);归约操作,同样两个类型的数据进行操作后返回相同类型的结果。比如两个整数相加、相乘等。
 maxOptional<T> max(Comparator<? super T> comparator)求最大值,根据Comparator计算的比较结果得到最大值
    
 minOptional<T> min(Comparator<? super T> comparator)求最小值,根据Comparator计算的比较结果得到最小值
    
汇总统计collect<R, A> R collect(Collector<? super T, A, R> collector)汇总操作,汇总对应的处理结果。这里经常与
 countlong count()统计流中数据数量
    
遍历foreachvoid forEach(Consumer<? super T> action)遍历操作,遍历执行Consumer 对应的操作

上面是Stream API的一些常用操作,按场景结合lambda表达式调用对应方法即可。至于Stream的生成方式,Stream的of方法或者Collection接口实现类的stream方法都可以获得对应的流对象,再进一步根据需要做对应处理。

另外上述方法如果返回是Stream对象时是可以链式调用的,这个时候这个操作只是声明或者配方,不产生新的集合,这种类型的方法是惰性求值方法;有些方法返回结果非Stream类型,则是及早求值方法。

“为什么要区分惰性求值和及早求值? 只有在对需要什么样的结果和操 作有了更多了解之后, 才能更有效率地进行计算。 例如, 如果要找出大于 10 的第一个数字, 那么并不需要和所有元素去做比较, 只要找出第一个匹配的元素就够了。 这也意味着可以在集合类上级联多种操作, 但迭代只需一次。这也是函数编程中惰性计算的特性,即只在需要产生表达式的值时进行计算。这样代码更加清晰,而且省掉了多余的操作。

这里还对上述列表操作中相关的Optional与Collectors类做下说明。

Optional类是为了解决经常遇到的NullPointerException出现的,这个类是一个可能包含空值的容器类。用Optional替代null可以显示说明结果可能为空或不为空,再使用时使用isPresent方法判断就可以避免直接调用的空指针异常。

Collectors类是一个非常有用的是归约操作工具类,工具类中的方法常与流的collect方法结合使用。比如
groupingBy方法可以用来分组,在转化Map时非常实用;partitioningBy方法可以用来分区(分区可以当做一种特殊的分组,真假值分组),joining方法可以用来连接,这个应用在比如字符串拼接的场景。

2.3 并行流

Collection接口的实现类调用parallelStream方法就可以实现并行流,相应地也获得了并行计算的能力。或者Stream接口的实现调用parallel方法也可以得到并行流。并行流实现机制是基于fork/join 框架,将问题分解再合并处理。

不过并行计算是否一定比串行快呢?这也不一定。实际影响性能的点包括:
(1)数据大小输入数据的大小会影响并行化处理对性能的提升。 将问题分解之后并行化处理, 再将结果合并会带来额外的开销。 因此只有数据足够大、 每个数据处理管道花费的时间足够多
时, 并行化处理才有意义。
(2) 源数据结构
每个管道的操作都基于一些初始数据源, 通常是集合。 将不同的数据源分割相对容易,这里的开销影响了在管道中并行处理数据时到底能带来多少性能上的提升。
(3) 装箱
处理基本类型比处理装箱类型要快。
(4) 核的数量
极端情况下, 只有一个核, 因此完全没必要并行化。 显然, 拥有的核越多, 获得潜在性能提升的幅度就越大。 在实践中, 核的数量不单指你的机器上有多少核, 更是指运行时你的机器能使用多少核。 这也就是说同时运行的其他进程, 或者线程关联性( 强制线程在某些核或 CPU 上运行) 会影响性能。
(5) 单元处理开销
比如数据大小, 这是一场并行执行花费时间和分解合并操作开销之间的战争。 花在流中
每个元素身上的时间越长, 并行操作带来的性能提升越明显。

实际在考虑是否使用并行时需要考虑上面的要素。在讨论流中单独操作每一块的种类时, 可以分成两种不同的操作: 无状态的和有状态的。无状态操作整个过程中不必维护状态, 有状态操作则有维护状态所需的开销和限制。如果能避开有状态, 选用无状态操作, 就能获得更好的并行性能。 无状态操作包括 map、filter 和 flatMap, 有状态操作包括 sorted、 distinct 和 limit。这种理解在理论上是更好的,当然实际使用还是以测试结果最为可靠 。

三、方法引用

方法引用的基本思想是,如果一个Lambda代表的只是“直接调用这个方法”,那最好还是用名称来调用它,而不是去描述如何调用它。事实上,方法引用就是让你根据已有的方法实现来创建Lambda表达式。但是,显式地指明方法的名称,你的代码的可读性会更好。所以方法引用只是在内容中只有一个表达式的简写。

当 你 需 要使用 方 法 引用时 , 目 标引用 放 在 分隔符::前 ,方法 的 名 称放在 后 面 ,即ClassName
:: methodName
 。例如 ,Apple::getWeight就是引用了Apple类中定义的方法getWeight。请记住,不需要括号,因为你没有实际调用这个方法。方法引用就是Lambda表达式(Apple
a) -> a.getWeight()
的快捷写法。

这里有种情况需要特殊说明,就是类的构造函数情况,这个时候是通过ClassName::new这种形式创建Class构造函数对应的引用,例如:

图片[3]-jdk8和jdk11区别-京讯网络

Image.png

四、默认方法

4.1 介绍

为了以兼容方式改进API,Java 8中加入了默认方法。主要是为了支持库设计师,让他们能够写出更容易改进的接口。具体写法是在接口中加default关键字修饰。

4.2 使用说明

默认方法由于是为了避免兼容方式改进API才引入,所以一般正常开发中不会使用,除非你也想改进API,而不影响老的接口实现。当然在JDK8有大量的地方用到了默认方法,所以对这种写法有一定的了解还是有帮助的。
采用默认方法之后,你可以为这个方法提供一个默认的实现,这样实体类就无需在自己的实现中显式地提供一个空方法,而是默认就有了实现。

4.3 注意事项

由于类可以实现多个接口,也可以继承类,当接口或类中有相同函数签名的方法时,这个时候到底使用哪个类或接口的实现呢?
这里有三个规则可以进行判断:
(1) 类中的方法优先级最高。类或父类中声明的方法的优先级高于任何声明为默认方法的优先级。
(2) 如果无法依据第一条进行判断,那么子接口的优先级更高:函数签名相同时,优先选择拥有最具体实现的默认方法的接口,即如果B继承了A,那么B就比A更加具体。
(3) 最后,如果还是无法判断,继承了多个接口的类必须通过显式覆盖和调用期望的方法,显式地选择使用哪一个默认方法的实现。不然编译都会报错。

五、方法参数反射

官方教程地址

JDK8 新增了Method.getParameters方法,可以获取参数信息,包括参数名称。不过为了避免.class文件因为保留参数名而导致.class文件过大或者占用更多的内存,另外也避免有些参数( secret/password)泄露安全信息,JVM默认编译出的class文件是不会保留参数名这个信息的。

这一选项需由编译开关 javac -parameters 打开,默认是关闭的。在Eclipse(或者基于Eclipse的IDE)中可以如下图勾选保存:

图片[4]-jdk8和jdk11区别-京讯网络

Image.png

六、日期/时间改进

1.8之前JDK自带的日期处理类非常不方便,我们处理的时候经常是使用的第三方工具包,比如commons-lang包等。不过1.8出现之后这个改观了很多,比如日期时间的创建、比较、调整、格式化、时间间隔等。
这些类都在java.time包下。比原来实用了很多。

6.1 LocalDate/LocalTime/LocalDateTime

LocalDate为日期处理类、LocalTime为时间处理类、LocalDateTime为日期时间处理类,方法都类似,具体可以看API文档或源码,选取几个代表性的方法做下介绍。

now相关的方法可以获取当前日期或时间,of方法可以创建对应的日期或时间,parse方法可以解析日期或时间,get方法可以获取日期或时间信息,with方法可以设置日期或时间信息,plus或minus方法可以增减日期或时间信息;

6.2 TemporalAdjusters

这个类在日期调整时非常有用,比如得到当月的第一天、最后一天,当年的第一天、最后一天,下一周或前一周的某天等。

6.3 DateTimeFormatter

以前日期格式化一般用SimpleDateFormat类,但是不怎么好用,现在1.8引入了DateTimeFormatter类,默认定义了很多常量格式(ISO打头的),在使用的时候一般配合LocalDate/LocalTime/LocalDateTime使用,比如想把当前日期格式化成yyyy-MM-dd hh:mm:ss的形式:

  1. LocalDateTime dt = LocalDateTime.now();
  2. DateTimeFormatter dtf = DateTimeFormatter.ofPattern(“yyyy-MM-dd hh:mm:ss”);
  3. System.out.println(dtf.format(dt));

看到这里相信大家已经明白JDK8与JDK11的区别了

© 版权声明
THE END
喜欢就支持一下吧
点赞14.1W+打赏 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容