zystrivego
0%

Java

发表于 更新于 Valine：

Java的学习笔记

Stream

常用操作及API

出自Core Java Volume 2 Chapter 1

java/util/stream/Stream.java 源码中分为以下几类

  • intermediate operation.

  • stateful intermediate operation.

  • short-circuiting stateful intermediate operation.

  • terminal operation.

  • short-circuiting terminal operation.

非常用操作

  1. 主要是Collectors类里的各种收集结果的约简操作
  2. 基本类型流
  3. 并行流（在多CPU，使用并发流效率最高）

try-with-resources

深入理解 Java try-with-resource 语法糖

背景

众所周知，所有被打开的系统资源，比如流、文件或者Socket连接等，都需要被开发者手动关闭，否则随着程序的不断运行，资源泄露将会累积成重大的生产事故。

在Java的江湖中，存在着一种名为finally的功夫，它可以保证当你习武走火入魔之时，还可以做一些自救的操作。在远古时代，处理资源关闭的代码通常写在finally块中。然而，如果你同时打开了多个资源，那么将会出现噩梦般的场景：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class Demo {
    public static void main(String[] args) {
        BufferedInputStream bin = null;
        BufferedOutputStream bout = null;
        try {
            bin = new BufferedInputStream(new FileInputStream(new File("test.txt")));
            bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")));
            int b;
            while ((b = bin.read()) != -1) {
                bout.write(b);
            }
        }
        catch (IOException e) {
            e.printStackTrace();
        }
        finally {
            if (bin != null) {
                try {
                    bin.close();
                }
                catch (IOException e) {
                    e.printStackTrace();
                }
                finally {
                    if (bout != null) {
                        try {
                            bout.close();
                        }
                        catch (IOException e) {
                            e.printStackTrace();
                        }
                    }
                }
            }
        }
    }
}复制代码

Oh My God！！！关闭资源的代码竟然比业务代码还要多！！！这是因为，我们不仅需要关闭BufferedInputStream，还需要保证如果关闭BufferedInputStream时出现了异常， BufferedOutputStream也要能被正确地关闭。所以我们不得不借助finally中嵌套finally大法。可以想到，打开的资源越多，finally中嵌套的将会越深！！！

更为可恶的是，Python程序员面对这个问题，竟然微微一笑很倾城地说：“这个我们一点都不用考虑的嘞~”：

img

但是兄弟莫慌！我们可以利用Java 1.7中新增的try-with-resource语法糖来打开资源，而无需码农们自己书写资源来关闭代码。妈妈再也不用担心我把手写断掉了！我们用try-with-resource来改写刚才的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class TryWithResource {
    public static void main(String[] args) {
        try (BufferedInputStream bin = new BufferedInputStream(new FileInputStream(new File("test.txt")));
             BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream(new File("out.txt")))) {
            int b;
            while ((b = bin.read()) != -1) {
                bout.write(b);
            }
        }
        catch (IOException e) {
            e.printStackTrace();
        }
    }
}复制代码

是不是很简单？是不是很刺激？再也不用被Python程序员鄙视了！好了，下面将会详细讲解其实现原理以及内部机制。

动手实践

为了能够配合try-with-resource，资源必须实现AutoClosable接口。该接口的实现类需要重写close方法：

1
2
3
4
5
6
7
8
9
public class Connection implements AutoCloseable {
    public void sendData() {
        System.out.println("正在发送数据");
    }
    @Override
    public void close() throws Exception {
        System.out.println("正在关闭连接");
    }
}复制代码

调用类：

1
2
3
4
5
6
7
8
9
10
public class TryWithResource {
    public static void main(String[] args) {
        try (Connection conn = new Connection()) {
            conn.sendData();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}复制代码

运行后输出结果：

1
2
3
正在发送数据
正在关闭连接
复制代码

通过结果我们可以看到，close方法被自动调用了。

原理

那么这个是怎么做到的呢？我相信聪明的你们一定已经猜到了，其实，这一切都是编译器大神搞的鬼。我们反编译刚才例子的class文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class TryWithResource {
    public TryWithResource() {
    }
    public static void main(String[] args) {
        try {
            Connection e = new Connection();
            Throwable var2 = null;
            try {
                e.sendData();
            } catch (Throwable var12) {
                var2 = var12;
                throw var12;
            } finally {
                if(e != null) {
                    if(var2 != null) {
                        try {
                            e.close();
                        } catch (Throwable var11) {
                            var2.addSuppressed(var11);
                        }
                    } else {
                        e.close();
                    }
                }
            }
        } catch (Exception var14) {
            var14.printStackTrace();
        }
    }
}复制代码

看到没，在第15~27行，编译器自动帮我们生成了finally块，并且在里面调用了资源的close方法，所以例子中的close方法会在运行的时候被执行。

异常屏蔽

我相信，细心的你们肯定又发现了，刚才反编译的代码（第21行）比远古时代写的代码多了一个addSuppressed。为了了解这段代码的用意，我们稍微修改一下刚才的例子：我们将刚才的代码改回远古时代手动关闭异常的方式，并且在sendData和close方法中抛出异常：

1
2
3
4
5
6
7
8
9
public class Connection implements AutoCloseable {
    public void sendData() throws Exception {
        throw new Exception("send data");
    }
    @Override
    public void close() throws Exception {
        throw new MyException("close");
    }
}复制代码

修改main方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class TryWithResource {
    public static void main(String[] args) {
        try {
            test();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
    private static void test() throws Exception {
        Connection conn = null;
        try {
            conn = new Connection();
            conn.sendData();
        }
        finally {
            if (conn != null) {
                conn.close();
            }
        }
    }
}复制代码

运行之后我们发现：

1
2
3
4
5
basic.exception.MyException: close
	at basic.exception.Connection.close(Connection.java:10)
	at basic.exception.TryWithResource.test(TryWithResource.java:82)
	at basic.exception.TryWithResource.main(TryWithResource.java:7)
	......复制代码

好的，问题来了，由于我们一次只能抛出一个异常，所以在最上层看到的是最后一个抛出的异常——也就是close方法抛出的MyException，而sendData抛出的Exception被忽略了。这就是所谓的异常屏蔽。由于异常信息的丢失，异常屏蔽可能会导致某些bug变得极其难以发现，程序员们不得不加班加点地找bug，如此毒瘤，怎能不除！幸好，为了解决这个问题，从Java 1.7开始，大佬们为Throwable类新增了addSuppressed方法，支持将一个异常附加到另一个异常身上，从而避免异常屏蔽。那么被屏蔽的异常信息会通过怎样的格式输出呢？我们再运行一遍刚才用try-with-resource包裹的main方法：

1
2
3
4
5
6
7
8
9
java.lang.Exception: send data

	at basic.exception.Connection.sendData(Connection.java:5)
	at basic.exception.TryWithResource.main(TryWithResource.java:14)
	......
	Suppressed: basic.exception.MyException: close
		at basic.exception.Connection.close(Connection.java:10)
		at basic.exception.TryWithResource.main(TryWithResource.java:15)
		... 5 more复制代码

可以看到，异常信息中多了一个Suppressed的提示，告诉我们这个异常其实由两个异常组成，MyException是被Suppressed的异常。可喜可贺！

一个小问题

在使用try-with-resource的过程中，一定需要了解资源的close方法内部的实现逻辑。否则还是可能会导致资源泄露。

举个例子，在Java BIO中采用了大量的装饰器模式。当调用装饰器的close方法时，本质上是调用了装饰器内部包裹的流的close方法。比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class TryWithResource {
    public static void main(String[] args) {
        try (FileInputStream fin = new FileInputStream(new File("input.txt"));
                GZIPOutputStream out = new GZIPOutputStream(new FileOutputStream(new File("out.txt")))) {
            byte[] buffer = new byte[4096];
            int read;
            while ((read = fin.read(buffer)) != -1) {
                out.write(buffer, 0, read);
            }
        }
        catch (IOException e) {
            e.printStackTrace();
        }
    }
}复制代码

在上述代码中，我们从FileInputStream中读取字节，并且写入到GZIPOutputStream中。GZIPOutputStream实际上是FileOutputStream的装饰器。由于try-with-resource的特性，实际编译之后的代码会在后面带上finally代码块，并且在里面调用fin.close()方法和out.close()方法。我们再来看GZIPOutputStream类的close方法：

1
2
3
4
5
6
7
8
9
public void close() throws IOException {
    if (!closed) {
        finish();
        if (usesDefaultDeflater)
            def.end();
        out.close();
        closed = true;
    }
}复制代码

我们可以看到，out变量实际上代表的是被装饰的FileOutputStream类。在调用out变量的close方法之前，GZIPOutputStream还做了finish操作，该操作还会继续往FileOutputStream中写压缩信息，此时如果出现异常，则会out.close()方法被略过，然而这个才是最底层的资源关闭方法。正确的做法是应该在try-with-resource中单独声明最底层的资源，保证对应的close方法一定能够被调用。在刚才的例子中，我们需要单独声明每个FileInputStream以及FileOutputStream：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class TryWithResource {
    public static void main(String[] args) {
        try (FileInputStream fin = new FileInputStream(new File("input.txt"));
                FileOutputStream fout = new FileOutputStream(new File("out.txt"));
                GZIPOutputStream out = new GZIPOutputStream(fout)) {
            byte[] buffer = new byte[4096];
            int read;
            while ((read = fin.read(buffer)) != -1) {
                out.write(buffer, 0, read);
            }
        }
        catch (IOException e) {
            e.printStackTrace();
        }
    }
}复制代码

由于编译器会自动生成fout.close()的代码，这样肯定能够保证真正的流被关闭。

参考资料

  1. 官方文档
  2. 详解try-with-resource

分布式事务

  1. 阿里-SeaTa
  2. hmily-tcc
  3. rocketmq的事务消息

分布式锁

基于数据库表记录的方式

适用于单库多服务实例的场景

表名：distributed_lock_t

字段：

  1. 锁名称(lock_name)，区分业务场景
  2. 锁拥有者线程ID(owner_thread_id)，实现可重入锁，同一线程多个方法都可以获取到这把锁。
  3. 请求上下文信息(req_info)，记录获取线程的类和方法
  4. 锁获取时间(lock_acquired_time)
  5. 锁过期时间(lock_expired_time)，防止因为异常锁未释放。

基于redis

详见redis博客

JVM

常量池

  • JDK1.7之前

  在jdk1.7之前，常量池是存放在方法区中的。
在这里插入图片描述

  • JDK1.7

  在jdk1.7中，字符串常量池移到了堆中，运行时常量池还在方法区中。
在这里插入图片描述

  • JDK1.8

  jdk1.8删除了永久代，方法区这个概念还是保留的，但是方法区的实现变成了元空间，常量池沿用jdk1.7，还是放在了堆中。这样的效果就变成了：常量池和静态变量存储到了堆中，类的元数据及运行时常量池存储到元空间中。
在这里插入图片描述
  为啥要把方法区从JVM内存（永久代）移到直接内存（元空间）？主要有两个原因：

  1. 直接内存属于本地系统的IO操作，具有更高的一个IO操作性能，而JVM的堆内存这种，如果有IO操作，也是先复制到直接内存，然后再去进行本地IO操作。经过了一系列的中间流程，性能就会差一些。非直接内存操作：本地IO操作——>直接内存操作——>非直接内存操作——>直接内存操作——>本地IO操作，而直接内存操作：本地IO操作——>直接内存操作——>本地IO操作。
  2. 永久代有一个无法调整更改的JVM固定大小上限，回收不完全时，会出现OutOfMemoryError问题；而直接内存（元空间）是受到本地机器内存的限制，不会有这种问题。
  • 变化
  1. 在JDK1.7前，运行时常量池+字符串常量池是存放在方法区中，HotSpot VM对方法区的实现称为永久代。
  2. 在JDK1.7中，字符串常量池从方法区移到堆中，运行时常量池保留在方法区中。
  3. 在JDK1.8中，HotSpot移除永久代，使用元空间代替，此时字符串常量池保留在堆中，运行时常量池保留在方法区中，只是实现不一样了，JVM内存变成了直接内存。

【参考】
JVM——字符串常量池详解 - Andya_net - 博客园 (cnblogs.com)

​

性能优化

性能瓶颈

  • 慢查询，低效业务代码(方案)

  • 数据库查询太多

  • 并发问题

  • 内存溢出

  • 程序配置

  • 数据库慢(不应该用关系型)

  • GC停顿

PDCA循环

  • Plan

通过工具分析CPU，IO，GC，时间消耗等分析性能优化关键点。指定相应方案。

  • Do

建立当前优化前程序的性能指标CPU，IO，GC，IOPS等，根据指定的方案，优化方案，编码，数据库，JVM等。

  • Check

通过工具，日志，度量出改进后的程序运行情况。通过指标对比确认优化效果。

  • Act
    分析当前优化的关键点，持续改进和优化，方便导入下轮plan

部署调优

-X:传递一些信息给JVM

-XX:设置JVM的一些高级属性

  1. 根据实际情况设置xms，xmx，避免使用默认值。xms默认为物理内存的1/64，xmx则是1/4，很多微服务最大堆内存都用不到1G。Jvm占用的物理内存总大小大概为2.5倍的xmx。

  2. 建议xms和xmx设置成一样值

如果不一样，堆内存发生变化时，会扩堆或缩堆，如果xms设置过小，就会频繁GC。环境内存不富余，所有进程内存占用最大值叠加超过了物理内存最大值，则不建议。

  1. 建议按实际情况设置xss值

每当启动一个新线程，JVM会在虚拟机栈为它分配个线程栈。线程栈用来保存函数地址，参数，返回值信息，调用层次越深，参数，返回值越大，所需的线程栈也越大。默认值为1024KB，一般情况256KB就够了，如果内存富余不建议调整该参数。

JDK工具

  1. jps 查看Java进程ID

  2. jstat 监控JVM情况

  3. jstack 查看栈信息

  4. jmap 导出jvm堆栈信息

  5. jhat 分析导出的堆栈信息

  6. jinfo 查询或设置JVM属性

  7. jcmd 向jvm发送命令

Linux 常用命令

  • top

  • sar

  • pidstat

  • vmstat

  • iostat

  • mat eclipse的内存分析工具

  • pmap

Java监测工具

jprofiler(收费)，jvisualvm（jdk）， jconslole (jdk)本地性能分析

asyncprofiler:idea绑定的profiler

arthas 线上分析

BTrace 线上分析，弱于arthas

JVM优化案例

堆内存问题

问题高发区

jmap -heap pid

看老年区问题 一般都是这里溢出

jstat -gcutil pid 1000

每隔一秒打印gc快照，分析fgc和fgct是不是异常

jmap -histo pid 看哪个对象的实例最多

元空间内存溢出问题

引入第三方开源包可能会导致元空间不够

一个类定义在元空间中平均是4K大小，建议配置大于256M

堆外内存问题

64M块问题 malloc_arena_max

pmap分析内存-gdb分析堆外内存-找内存信息dump

GC速度慢

看磁盘看CPU，看swap看文件锁，看cgroup

young gc和cms gc容易受swap虚拟内存影响

看cgroup是否限制了内存使用，把JVM的内存限制到虚拟内存上了。

高性能编码

测试工具

  1. http web压测工具 ApacheBench，JMeter

  2. JMH jdk9自带，代码微基准测试工具

  3. 单元测试:Junit5+Mockito

字符串

  1. 避免循环中使用string#match，会创建新的pattern对象。

  2. Java8及以前的string.replace相关和split会创建新的pattern对象，避免循环调用。

  3. 避免在循环中使用string#format或message#format，使用string加号拼接或者stringbuilder

集合

ArrayList和linkedlist，头部的增删是linkedlist效率高，其它则是ArrayList(在不考虑扩容的情况下)

  1. 避免循环中用linklist带index的方法用ArrayList代替
  2. 循环中remove带index的元素建议使用list#sublist#clear，避免重复拷贝
  3. 不变集合可以使用guava的immutablemap或immutablelist等
  4. 知道确定元素个数时，集合初始化大小，list即所需大小，map为（所需大小/0.75)+1，避免频繁动态扩容，建议使用工具类，如Guava
  5. 避免创建小集合，1-4个元素的集合，建议创建数组，数组占用16字节，ArrayList24，hashmap48
  6. 避免创建稀疏的集合，ArrayList的trimtosize可以节省空间
  7. 避免循环中使用list#contain(obj)，indexOf等相关方法，复杂度是O(m*n)，善用set，hash效率更高，list的contain是比较equals方法，set的则是先比较hashcode，再比较equals方法
  8. system.arraycopy更高效

JUC

  1. countdownlatch await锁主线程，实时系统多并发场景
  2. cyclicbarrier await锁子线程，批处理系统实现任务顺序协调
  3. semaphore，控制多线程访问有限特定资源，适合令牌节流，资源池共享
  4. copy-on-write模式缺点:占用内存，最终一致性，适合多读少些场景。
  5. 优雅关闭线程池

关闭线程池有两种方式：shutdown() 和 shutdownNow()，二者最大的区别是 shutdown() 只是把空闲的 woker 置为中断，不影响正在运行的woker，并且会继续把待执行的任务给处理完。shutdonwNow() 则是把所有的 woker 都置为中断，待执行的任务全部抽出并返回，日常工作中更多是使用 shutdown()。

最后，单纯的使用 shutdown() 也不靠谱，还得使用 awaitTermination() 和 JVM 的钩子，才算优雅的关闭线程池。

  1. IO密集性重写线程池，借鉴Tomcat，dubbo，taskqueue，threadpoolexecutor

jdk的线程池是coreSize–>queue–>maxSize

改造后：coreSize–>maxSize–>queue

JVM

  1. 字符串优化，-XX：+useG1GC +usestringdeduplication
  2. 编译和运行时优化:内联优化，useappcds

web容器

  1. Tomcat启动优化:跳过扫描tld文件
  2. 返回数据Gzip压缩
  3. 从httpresponse获取的InputStream直接转成Java对象，不要先转string再转对象，容易造成内存占用