傅永德 | 个人博客

本文为基于 JaCoCo 源码二次开发的全流程方案，旨在实现类局部修改后保留未改动方法历史覆盖率，仅失效改动方法覆盖率的核心诉求，兼顾 JaCoCo 原生正确性原则与业务实用性。

一、核心目标与不可突破原则

1.1 核心开发目标

• 类局部修改（方法 / 代码块修改）时，未改动方法的历史覆盖率完全复用，改动方法覆盖率清零并重新统计；
• 完全兼容 JaCoCo 原生能力：插桩方式（动态 / 离线）、覆盖率维度、dump 文件格式、构建插件（Maven/Gradle）；
• 坚守正确性底线：仅当方法字节码逻辑完全未变时才复用覆盖率，杜绝错误数据。

1.2 不可突破原则

• 正确性原则：复用数据必须基于方法逻辑一致性，方法体改动则覆盖率强制失效；
• 向下兼容原则：改造后 JaCoCo 可解析原生 dump 文件，原生 JaCoCo 可解析改造后文件（降级兼容）；
• 无侵入原则：业务侧无感知，使用方式与原生 JaCoCo 一致，新增开关控制功能。

1.3 核心改造思想

原生 JaCoCo 以 类级别 ClassID 绑定覆盖率数据，类变更则全量失效；改造后下沉为 方法级别 MethodID 绑定，实现方法级粒度的失效与复用，核心逻辑如下：

• 覆盖率数据存储结构从 ClassID + 全局探针ID → ClassID + MethodID + 方法内局部探针ID

二、前置准备

最近使用 Guava 中 RateLimiter.getRate() 方法时遇到了一个反直觉的现象，这里贴出来给大家分享一下。

现象

我们先看下下面这段代码

1
2
3
4
5

public static void main(String[] args) {
    RateLimiter rateLimiter = RateLimiter.create(10.0D);
    double rate = rateLimiter.getRate();
    System.out.println(rate);
}

直觉上最终会输出 10.0，实际最终也是输出了 10.0。

可是如果我们将上述代码中的 10.0D 变为 15.0D，结果会输出什么呢？

1
2
3
4
5

public static void main(String[] args) {
    RateLimiter rateLimiter = RateLimiter.create(15.0D);
    double rate = rateLimiter.getRate();
    System.out.println(rate);
}

执行后输出的值竟然是 14.999999999999998。看到这个结果我觉得非常的奇怪，毕竟直觉告诉我应该输出 15.0 才对。

刨根问底

看到这样的现象，我们首先就要从源码上分析一下，看一下 Guava 内部是如何处理的。

JaCoCo 简介

JaCoCo should provide the standard technology for code coverage analysis in Java VM based environments. The focus is providing a lightweight, flexible and well documented library for integration with various build and development tools.

JaCoCo 要为基于 Java VM 的环境中的代码提供覆盖率分析标准技术，重点是提供一个轻量、灵活且文档齐全的库，以便与各种构建和开发工具集成。

功能特性

• 指令（C0）、分支（C1）、行、方法、类型、圈复杂度的覆盖率分析；
• 基于 Java 字节码，即使没有源码依然可以运行；
• 支持 on-the-fly 模式，可以通过 javaagent 便捷地集成，也可以通过 API 来自定义类装载器进行集成；
• 与框架无关，可以对基于 Java VM 的应用程序顺利的集成；
• 与已所有已发布的 Java 版本兼容；
• 支持不同的 JVM 语言；
• 可以生成多种格式的报告（HTML、XML、CSV）；
• 支持远程协议和 JMX 控制，可以在任何时间点来进行覆盖率数据的存储；

使用

下载完 JaCoCo 之后会得到几个 jar 包，其中 jacocoagent.jar 和 jacococli.jar 是我们比较关注的。

• jacocoagent.jar 是 JVM 应用程序启动时的代理
• jacococli.jar 是生成覆盖率报告、合并 dump 文件的命令行工具

jacocoagent

Java Agent 的原理可以阅读 java.lang.instrument.Instrumentation 这个类，这里先介绍 jacocoagent 的使用方法。

最近在做基于 JaCoCo 的代码覆盖率工具，了解到了一下 javaagent 相关的一些知识点。

javaagent 是什么？

javaagent 是 java 命令的一个参数选项，可以用于加载 Java 语言的代理。

那么这个参数加载的 Java 语言的代理需要满足什么样的规范呢？

1. 代理 jar 包中的 MANIFEST.MF 文件需指定 Premain-Class；
2. Premain-Class 指定的类中必须实现 premain 方法。

zsh 可能是目前最好用的终端。

安装

Mac OS

macOS 自带 zsh，并且当前最新版本 macOS 默认终端即为 zsh

Ubuntu

使用 sudo apt install zsh 命令即可安装 zsh

CentOS

使用 sudo yum install zsh 命令即可安装 zsh

在安装好 zsh 之后，第一次使用的时候，会有如下的提示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

This is the Z Shell configuration function for new users,
zsh-newuser-install.
You are seeing this message because you have no zsh startup files
(the files .zshenv, .zprofile, .zshrc, .zlogin in the directory
~).  This function can help you with a few settings that should
make your use of the shell easier.

You can:

(q)  Quit and do nothing.  The function will be run again next time.

(0)  Exit, creating the file ~/.zshrc containing just a comment.
     That will prevent this function being run again.

(1)  Continue to the main menu.

(2)  Populate your ~/.zshrc with the configuration recommended
     by the system administrator and exit (you will need to edit
     the file by hand, if so desired).

--- Type one of the keys in parentheses ---

使用 Spring 做项目的先思考一个问题，一个接口有在多个实现类的情况下，在成员变量的声明上如果没有指定注入那个别名的 Bean 的时候 Spring 会如何选择对应的 Bean 来进行注入？

问题模拟

先来简单说明一下示例代码。

定义一个接口，用于打印当前注入的 Bean 的名称

1
2
3

public interface TestService {
    void printBeanName();
}

针对上面定义的接口编写两个实现类，并分别定义其 beanName 为 testService 和 testService2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Service("testService")
public class TestServiceImpl implements TestService {

    @Override
    public void printBeanName() {
        System.out.println("testService");
    }
}

@Service("testService2")
public class TestServiceImpl2 implements TestService {

    @Override
    public void printBeanName() {
        System.out.println("testService2");
    }
}

编写 Handler，并注入 TestService

1
2
3
4
5
6
7
8
9
10

@Service
public class TestHandler {

    @Autowired
    private TestService testService;

    public void test() {
        testService.printBeanName();
    }
}

编写单元测试，并观察输出

线上业务使用了 Guava 中的 RateLimiter 来做单机的限流。最近运维同事反馈，在修改了限流的配置之后，请求频率没有超过限流的配置却触发了限流逻辑，在此对该问题进行一下分析与总结。

问题模拟

根据上述问题的现象，初步推测问题可能跟 Guava 中 RateLimiter 的限流算法实现有关，为了方便排查问题，参考线上业务的限流的逻辑写了一个 demo，其核心代码如下：

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
38
39
40
41
42
43
44
45
46
47
48
49

@RestController
@RequestMapping("/hello")
public class HelloController {

    /** 用于存储不同的接口，对应的 RateLimiter **/
    private static Map<String, RateLimiter> RATE_LIMITER_MAP = Maps.newConcurrentMap();
    /** 用于存储不同接口限流配置的参数 **/
    private static Map<String, String> RATE_MAP = Maps.newConcurrentMap();

    static {
        // 初始化一个接口默认的限流配置
        RATE_MAP.put("loan", "100000");
    }

    /**
     * 测试限流的接口
     * @param key 限流配置的 key
     */
    @GetMapping("/testLimit")
    public String testLimit(String key) {
        String value = RATE_MAP.get(key);
        logger.info("自定义限流配置={}", value);
        Double currentRate = Double.parseDouble(value);

        RateLimiter rateLimiter = RATE_LIMITER_MAP.get(key);
        if (rateLimiter == null || !isSameRate(currentRate, rateLimiter.getRate())) {
            logger.info("创建新的RateLimiter|速率={}", currentRate.toString());
            rateLimiter = RateLimiter.create(currentRate);
            RATE_LIMITER_MAP.putIfAbsent(key, rateLimiter);
        }
        boolean allowed = rateLimiter.tryAcquire();
        logger.info("是否允许当前请求通过={}|rate={}", allowed, rateLimiter.getRate());
        return allowed ? "SUCCESS" : "FAIL";
    }

    /**
     * 模拟修改限流配置
     * @param key 限流配置的key
     * @param rate 限流的值
     */
    @GetMapping("/setRate")
    public String setRate(String key, String rate) {
        RATE_MAP.put(key, rate);
        String currentValue = RATE_MAP.get(key);
        logger.info("设置完之后的值={}", currentValue);
        return "SUCCESS";
    }

}

启动工程，我们模拟一下出现问题时的操作。

1. 构造 HTTP 请求调用 /setRate 接口，将 loan 对应的限流的值修改为 5；
2. 构造 HTTP 请求快速调用 /testLimit 接口 2 次，发现第一次调用接口返回 SUCCESS，第二次接口返回 FAIL，说明第 2 次请求触发了限流；
3. 构造 HTTP 请求调用 /testLimit 5 次，保证 5 次请求在 1 秒内接收，发现这 5 次请求接口均返回 SUCCESS，说明这 5 次请求均未触发限流；
4. 构造 HTTP 请求调用 /testLimit 6 次，保证 6 次请求均在 1 秒内接收，发现前 6 次请求接口均返回 SUCCESS，说明这 6 次请求均未触发限流；
5. 构造 HTTP 请求调用 /testLimit 7 次，保证 7 次请求均在 1 秒内接收，发现前 6 次请求接口均返回 SUCCESS，第 7 次请求接口返回 FAIL，说明前 6 次请求均未触发限流，第 7 次请求触发限流。

至此，我们模拟的现象与线上一致。步骤 3 是我们预期的结果，步骤 2 中在未超过限流配置的情况下触发了限流，步骤 4、5 中的第 6 次请求在超过了限流配置的情况下，仍然允许通过，我们直观上认为这些是不合理的。

排查与分析

Guava 中 RateLimiter 提供了两种令牌桶的算法实现：

• 平滑突发限流（SmoothBursty）
• 平滑预热限流（SmoothWarmingUp）

近期收到一些小伙伴问 Java 中如何调用 https 中双向认证的接口的问题，本文采用 okhttp 以及 Java11 中的 httpclient 来介绍如何使用 Java 代码调用 https 双向认证的接口。

前置工作

1. 生成服务端、客户端证书，并将各自的公钥加入到对方的信任链中以供后续的使用；
2. 搭建一个 https 协议的服务以供客户端调用。

制作证书

这里我们采用 jdk 提供的 keytool 命令来生成我们所需要的服务端、客户端证书，并且可以使用 keytool 命令来将各自的公钥加入到对方的信任连中。

生成服务端、客户端密钥库以及证书

1
2
3
4

# 生成服务端keystore，这里加拓展项的目的是为了说明域名验证的问题
keytool -genkey -validity 3650 -alias server -keyalg RSA -keystore server.keystore -ext san=dns:www.goku.edu,ip:127.0.0.1
# 生成客户端keystore，这里针对客户端的密钥库我们采用 PKCS12 的格式
keytool -genkey -validity 3650 -alias client -keyalg RSA -storetype PKCS12 -keystore client.p12

导出服务端、客户端证书中的公钥

1
2
3
4

# 导出服务端证书的公钥
keytool -export -keystore server.keystore -alias server -file server.cer -rfc
# 导出客户端证书的公钥
keytool -export -keystore client.p12 -storetype PKCS12 -alias client -file client.cer

将各自的公钥加入到对方的密钥库中

配置 npmmirror 镜像

1. 备份旧镜像

在替换 npmmirror 镜像之前，我们先查看一下原有的镜像

1

npm get registry

结果为 https://registry.npmjs.org/

1

yarn get registry

结果为 https://registry.yarnpkg.com

2. 替换为 npmmirror 镜像

1
2
3
4

# 设置 npm 的源为 npmmirror
npm config set registry https://registry.npmmirror.com
# 设置 yarn 的源为 npmmirror
yarn config set registry https://registry.npmmirror.com

升级版本

在日常开发中，如果我们一不小心删除了某个分支，又想重新使用这个分支，该怎么找回该分支上的代码呢？

场景还原

1. 有一个 git 仓库，从 master 分支新建 feature/delete_branch 分支，并进行一次提交，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

# 新建一个 feature/delete_branch 分支
git branch feature/delete_branch
# 切换到 feature/delete_branch 分支
git checkout feature/delete_branch
# 新建一个文件，进行一次提交并推送至远程分支
git add delete-file.md
git commit -m ':sparkles: add a delete-file.md file'
git push origin feature/delete_branch:feature/delete_branch

# 查看当前分支图
git log --all --decorate --oneline --graph
* 88ac246 (HEAD -> feature/delete_branch, origin/feature/delete_branch) :sparkles: add a delete-file.md file
* 8693480 (origin/master, master) :sparkles: add a hello-git.md file

2. 切换到 master 分支，并删除 feature/delete_branch 分支

1
2
3
4
5
6
7
8
9

# 切换到 master 分支
git checkout master
# 删除 feature/delete_branch 分支
git branch -d feature/delete_branch
# 将删除操作同步至远程
git push origin --delete feature/delete_branch
# 此时无论是本地还是远程都已经删除了 feature/delete_branch
git log --all --decorate --oneline --graph
* 8693480 (HEAD -> master, origin/master) :sparkles: add a hello-git.md file

还原删除的分支

1. 通过 git reflog 或 git log -g 命令找到我们需要恢复的 commit id

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
38
39
40

# 这里演示 git reflog 命令展示出来的提交
git reflog
8693480 (HEAD -> master, origin/master) HEAD@{0}: checkout: moving from feature/delete_branch to master
88ac246 (feature/delete_branch) HEAD@{1}: commit: :sparkles: add a delete-file.md file
8693480 (HEAD -> master, origin/master) HEAD@{2}: checkout: moving from master to feature/delete_branch
8693480 (HEAD -> master, origin/master) HEAD@{3}: commit (initial): :sparkles: add a hello-git.md file

# 这里演示 git log -g 命令展示出来的提交
git log -g
commit 86934803092ae7ae7266f9ebff3429437e423b80 (HEAD -> master, origin/master)
Reflog: HEAD@{0} (fuyongde <fuyongde@foxmail.com>)
Reflog message: checkout: moving from feature/delete_branch to master
Author: fuyongde <fuyongde@foxmail.com>
Date:   Thu Mar 26 18:36:35 2020 +0800

    :sparkles: add a hello-git.md file

commit 88ac246020a0cc25071fb7fd3ac88363f4bf2beb (feature/delete_branch)
Reflog: HEAD@{1} (fuyongde <fuyongde@foxmail.com>)
Reflog message: commit: :sparkles: add a delete-file.md file
Author: fuyongde <fuyongde@foxmail.com>
Date:   Thu Mar 26 18:44:01 2020 +0800

    :sparkles: add a delete-file.md file

commit 86934803092ae7ae7266f9ebff3429437e423b80 (HEAD -> master, origin/master)
Reflog: HEAD@{2} (fuyongde <fuyongde@foxmail.com>)
Reflog message: checkout: moving from master to feature/delete_branch
Author: fuyongde <fuyongde@foxmail.com>
Date:   Thu Mar 26 18:36:35 2020 +0800

    :sparkles: add a hello-git.md file

commit 86934803092ae7ae7266f9ebff3429437e423b80 (HEAD -> master, origin/master)
Reflog: HEAD@{3} (fuyongde <fuyongde@foxmail.com>)
Reflog message: commit (initial): :sparkles: add a hello-git.md file
Author: fuyongde <fuyongde@foxmail.com>
Date:   Thu Mar 26 18:36:35 2020 +0800

    :sparkles: add a hello-git.md file

2. 通过 git branch [branch name] [commit id] 命令来恢复删除的分支