JavaGuide自学目录4-IO&新特性

IO流

IO 流在 Java 中分为输入流和输出流，而根据数据的处理方式又分为字节流和字符流。

Java IO 流的 40 多个类都是从如下 4 个抽象类基类中派生出来的。

• InputStream/Reader: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。
• OutputStream/Writer: 所有输出流的基类，前者是字节输出流，后者是字符输出流。

常用字符编码所占字节数？utf8 :英文占 1 字节，中文占 3 字节，unicode：任何字符都占 2 个字节，gbk：英文占 1 字节，中文占 2 字节。

如果音频文件、图片等媒体文件用字节流比较好，如果涉及到（中文）字符的话使用字符流比较好。

IO 操作是很消耗性能的，缓冲流将数据加载至缓冲区，一次性读取/写入多个字节，从而避免频繁的 IO 操作，提高流的传输效率。

字节缓冲流这里采用了装饰器模式来增强 InputStream 和OutputStream子类对象的功能。

随机访问流可以支持随意跳转到文件的任意位置进行读写，RandomAccessFile

NIO

没看懂

JVM

正是因为 Java 程序员把内存控制权利交给 Java 虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会是一个非常艰巨的任务。

新特性

interface

为了解决接口的修改与现有的实现不兼容的问题。新 interface 的方法可以用default 或 static修饰，这样就可以有方法体，实现类也不必重写此方法。

static修饰的方法，子类就不能重写了。

functional interface

只要符合函数式接口的定义就是函数式接口.

定义：也称 SAM 接口，即 Single Abstract Method interfaces，有且只有一个抽象方法，但可以有多个非抽象方法的接口。

可以加一个@FunctionalInterface注解，注解只是在编译时起到强制规范定义的作用

lambda表达式

让一些写法更加紧凑

new Thread(() -> System.out.println("It's a lambda function!")).start();
Collections.sort(strings, (Integer o1, Integer o2) -> o1 - o2);

只要方法的参数是函数式接口都可以用 Lambda 表达式。

@FunctionalInterface
public interface Comparator<T>{}

@FunctionalInterface
public interface Runnable{}

lambda 表达式可以引用外边变量，但是该变量默认拥有 final 属性，不能被修改，如果修改，编译时就报错。

下面就会报错：

int x = 10;
Runnable r = () -> { x++; };

stream流

1. stream 串行流
2. parallelStream 并行流，可多线程执行

并行 parallelStream 在使用方法上和串行一样。主要区别是 parallelStream 可多线程执行，是基于 ForkJoin 框架实现的，有时间大家可以了解一下 ForkJoin 框架和 ForkJoinPool。这里可以简单的理解它是通过线程池来实现的，这样就会涉及到线程安全，线程消耗等问题

filter(过滤)，sorted（排序），map(映射)，match(匹配), count（计数），reduce(规约)

排序之后原数据 stringList 是不会被修改的。

// 测试 Map 操作
stringList.stream().map(String::toUpperCase).sorted((a, b) -> b.compareTo(a))
.forEach(System.out::println);// "DDD2", "DDD1", "CCC", "BBB3", "BBB2", "BBB1", "AAA2", "AAA1"

匹配的结果是boolean,有anyMatch(),allMatch(),noneMatch().

Optional

建议使用 Optional 解决 NPE（java.lang.NullPointerException）问题，它就是为 NPE 而生的，其中可以包含空值或非空值

防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：

1） 返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。

反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。

2） 数据库的查询结果可能为 null。

3） 集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。

4） 远程调用返回对象时，一律要求进行空指针判断，防止 NPE。

5） 对于 Session 中获取的数据，建议进行 NPE 检查，避免空指针。

6） 级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。

正例：使用 JDK8 的 Optional 类来防止 NPE 问题。

传统解决NPE的方法如下

Zoo zoo = getZoo();
if(zoo != null){
   Dog dog = zoo.getDog();
   if(dog != null){
      int age = dog.getAge();
      System.out.println(age);
   }
}

Optional的实现方法：

Optional.ofNullable(zoo).map(o -> o.getDog()).map(d -> d.getAge()).ifPresent(age ->
    System.out.println(age)
);

​

ofNullable 方法和of方法唯一区别就是当 value 为 null 时，ofNullable 返回的是EMPTY，of 会抛出 NullPointerException 异常。如果需要把 NullPointerException 暴漏出来就用 of，否则就用 ofNullable。

flatMap()可以将map()的结果展开. 在Stream和Optional中正确使用flatMap可以减少很多不必要的代码

全新的Date-Time

LocalDateTime.class //日期+时间 format: yyyy-MM-ddTHH:mm:ss.SSS
LocalDate.class //日期 format: yyyy-MM-dd
LocalTime.class //时间 format: HH:mm:ss

解决了 Date 类的大部分痛点：

1. 非线程安全
2. 时区处理麻烦
3. 各种格式化、和时间计算繁琐
4. 设计有缺陷，Date 类同时包含日期和时间；还有一个 java.sql.Date，容易混淆。

Java8之前用SimpleDateFormat去转。

LocalDate t1=LocalDate.now();
LocalTime t2=LocalTime.now();
LocalDateTime T3=LocalDateTime.now();
System.out.println(T3.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));

sout分别是

2023-11-20
19:23:56.353
2023-11-20T19:23:56.353

2023-11-20 19:23:56

字符串转日期格式。Java 8 之前 转换都需要借助 SimpleDateFormat 类，而Java 8 之后只需要 LocalDate、LocalTime、LocalDateTime的 of 或 parse 方法。

JAVA9

在 Java 8 的时候，默认垃圾回收器是 Parallel Scavenge（新生代）+Parallel Old（老年代）。到了 Java 9, CMS 垃圾回收器被废弃了，G1（Garbage-First Garbage Collector） 成为了默认垃圾回收器。

G1 还是在 Java 7 中被引入的，经过两个版本优异的表现成为成为默认垃圾回收。

在 Java 9 之后，String 的实现改用 byte[] 数组存储字符串，节省了空间。

JAVA10

从 Java9 开始 G1 就了默认的垃圾回收器，G1 是以一种低延时的垃圾回收器来设计的，旨在避免进行 Full GC,但是 Java9 的 G1 的 FullGC 依然是使用单线程去完成标记清除算法,这可能会导致垃圾回收期在无法回收内存的时候触发 Full GC。

为了最大限度地减少 Full GC 造成的应用停顿的影响，从 Java10 开始，G1 的 FullGC 改为并行的标记清除算法，同时会使用与年轻代回收和混合回收相同的并行工作线程数量，从而减少了 Full GC 的发生，以带来更好的性能提升、更大的吞吐

Java11

ZGC 即 Z Garbage Collector，是一个可伸缩的、低延迟的垃圾收集器。

ZGC 主要为了满足如下目标进行设计：

• GC 停顿时间不超过 10ms
• 即能处理几百 MB 的小堆，也能处理几个 TB 的大堆
• 应用吞吐能力不会下降超过 15%（与 G1 回收算法相比）
• 方便在此基础上引入新的 GC 特性和利用 colored 针以及 Load barriers 优化奠定基础
• 当前只支持 Linux/x64 位平台

ZGC 目前 处在实验阶段，只支持 Linux/x64 平台。

与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法，不过 ZGC 对该算法做了重大改进。

在 ZGC 中出现 Stop The World 的情况会更少！

Java12

Shenandoah GC

Redhat 主导开发的 Pauseless GC 实现，主要目标是 99.9% 的暂停小于 10ms，暂停与堆大小无关等

和 Java11 开源的 ZGC 相比（需要升级到 JDK11 才能使用），Shenandoah GC 有稳定的 JDK8u 版本，在 Java8 占据主要市场份额的今天有更大的可落地性。

G1 收集器优化

Java12 为默认的垃圾收集器 G1 带来了两项更新:

• 可中止的混合收集集合：JEP344 的实现，为了达到用户提供的停顿时间目标，JEP 344 通过把要被回收的区域集（混合收集集合）拆分为强制和可选部分，使 G1 垃圾回收器能中止垃圾回收过程。 G1 可以中止可选部分的回收以达到停顿时间目标
• 及时返回未使用的已分配内存：JEP346 的实现，增强 G1 GC，以便在空闲时自动将 Java 堆内存返回给操作系统

JAVA13

增强 ZGC(释放未使用内存)

在 Java 11 中实验性引入的 ZGC 在实际的使用中存在未能主动将未使用的内存释放给操作系统的问题。

ZGC 堆由一组称为 ZPages 的堆区域组成。在 GC 周期中清空 ZPages 区域时，它们将被释放并返回到页面缓存 ZPageCache 中，此缓存中的 ZPages 按最近最少使用（LRU）的顺序，并按照大小进行组织。

在 Java 13 中，ZGC 将向操作系统返回被标识为长时间未使用的页面，这样它们将可以被其他进程重用。

JAVA14

从 Java11 引入的 ZGC 作为继 G1 过后的下一代 GC 算法，从支持 Linux 平台到 Java14 开始支持 MacOS 和 Windows（个人感觉是终于可以在日常开发工具中先体验下 ZGC 的效果了，虽然其实 G1 也够用）

移除了 CMS(Concurrent Mark Sweep) 垃圾收集器（功成而退）

JAVA15

Java11 的时候 ，ZGC 还在试验阶段。

当时，ZGC 的出现让众多 Java 开发者看到了垃圾回收器的另外一种可能，因此备受关注。

经过多个版本的迭代，不断的完善和修复问题，ZGC 在 Java 15 已经可以正式使用了！

不过，默认的垃圾回收器依然是 G1。你可以通过下面的参数启动 ZGC：

$ java -XX:+UseZGC className

Nashorn JavaScript 引擎彻底移除：Nashorn 从 Java8 开始引入的 JavaScript 引擎，Java9 对 Nashorn 做了些增强，实现了一些 ES6 的新特性。在 Java 11 中就已经被弃用，到了 Java 15 就彻底被删除了。

禁用和废弃偏向锁（Biased Locking）：偏向锁的引入增加了 JVM 的复杂性大于其带来的性能提升。不过，你仍然可以使用 -XX:+UseBiasedLocking 启用偏向锁定，但它会提示 这是一个已弃用的 API。

JAVA16

JEP376:ZGC 并发线程堆栈处理

JAVA17

对switch增加了类型匹配自动转换功能。

JAVA19

虚拟线程（Virtual Thread-）是 JDK 而不是 OS 实现的轻量级线程(Lightweight Process，LWP），许多虚拟线程共享同一个操作系统线程，虚拟线程的数量可以远大于操作系统线程的数量。

相比较于平台线程来说，虚拟线程是廉价且轻量级的，使用完后立即被销毁，因此它们不需要被重用或池化，每个任务可以有自己专属的虚拟线程来运行。虚拟线程暂停和恢复来实现线程之间的切换，避免了上下文切换的额外耗费，兼顾了多线程的优点，简化了高并发程序的复杂，可以有效减少编写、维护和观察高吞吐量并发应用程序的工作量