问题痛点

最近维护了一段时间的组件包，在向同事进行推广的时候，经常会听到身边会有类似的抱怨：

• 我靠，为啥你们的包带了一大堆乱七八糟的依赖，把我的classpath都给污染的不像个样子了。
• 我靠，你们这个包依赖的xx包的版本跟我们自己依赖的xx包的版本不一样啊，会不会出锅？
• 我靠，我这个代码编译的时候没问题啊，为啥一用你们的组件就报一堆的NoSuchMethodError啊。

有时候自己写代码的时候也会遇到一些容易被忽略的问题：

• 哎，我看人家引这个包的时候都会exclude一些依赖，我要不要也学着exclude一下呢？不管了，先一起粘过来试试看。
• 哎，怎么我的classpath里的某个包有三四个不同的版本啊，跑的时候到底用的是哪个版本啊？不管了，反正差不多，先跑跑看。
• 哎，我怎么直接就可以用这个类了，这个类是哪个包引的？不管了，反正IDE爸爸提示我能用，先用着再说。

大多数情况下，忽略这些问题一般也不会造成太大的影响，就算出了线上bug，一般也能很快定位问题、强制指定一下依赖的版本号就好。但是不得不说，依赖调解是普通java开发人员经常会遇到的问题，无谓的浪费了我们大量的时间和精力。尤其是当项目越来越大，用到的组件越来越多时，内耗就更加明显。

业内方案

大概研究了一下，目前对于本地依赖调解也没有什么很好的银弹。绝大多数情况下，我们都是在流程、文档上来进行把控。而从技术角度说，或许有如下几种方案供我们选择。

代码内嵌

这个方法很老土，但是也好用，就是把依赖到的包以源代码的形式放在自己项目的包中，而不是以依赖的形式引入。这样的好处就是组件一定可以依赖到自己想要引入的包，不会收到业务方引入的包的影响。不过坏处就是缺少了灵活性，业务方无法修改组件包的任何依赖。

前言

前两天我们组负责的一个组件发生了一个与jar包版本号有关的线上bug，最近没啥事情，就顺便分析了一下。

其实是个非常无脑的小bug：commons-lang3包中有一堆@since 3.5的新增方法，我们的组件依赖了3.5版本以上的一个包；业务方依赖了我们的这个组件，同时也直接依赖了一个3.5版本以下的包。在gradle打包的时候，由于老版本的是直接依赖，新版本的是间接依赖，直接依赖优先级高于间接依赖，因此最终采用的是老版本的包。这就导致在运行期调用新方法的时候会报NoSuchMethod的错。

虽然问题很简单，但毕竟也是一个影响了GMV的线上事故（可怕），值得吸取一波教训。

方案

一般来说，在比较大的项目里，依赖冲突这种事情几乎是无法避免的。一般来说，这种问题的解决方法大多是下面几种：

1. 对于业务方来说，写代码的时候小心一点，遇到不同依赖的时候，有意识的检查一下依赖树，尽量使用较新的包，并且代码上线之前需要在测试环境充分测试。
2. 对于组件开发方来说，在写接入文档的时候要同时指明依赖的包的最低版本号，清楚地告诉接入方最低的依赖，然后再由接入方手动指定。
3. 采用容器技术，比如OSGI、Jigsaw、Karaf这些容器，对jar包再进行一层权限控制。这是一种十分重量级的方法，一般项目得上了一定的规模才会使用。
4. 采用ClassLoader隔离技术，各个包都使用自己的classLoader，互相不影响。这种方法其实很像是容器技术的阉割版，逻辑上很像容器，对jar包再做一层隔离控制。不过这种方式一般不是很优雅，有点像hack，因此目前看起来没什么像样的完整解决方案。稍微像样点的大概就是阿里最近搞的Sofa ark，功能挺强大，但是用起来也比较复杂，对jar包的侵入性也很强。

各个方法其实都不是很方便，那就换一个思路，既然避免问题比较困难，那就尽量早点暴露问题。编译错误或者启动错误肯定会比运行时不知道啥时候报错更让人放心。因此根据fail fast原则，我们应当保证在不增加沟通成本的情况下，快速暴露问题。

分析

既然很多依赖冲突问题在编译、打包时都不会报错，那就只能尽量在启动时报错了。因此对于一个稳定的组件来说，做一个运行时的启动检查也就有一定的合理性了。

前言

这个礼拜似乎是写了一礼拜的业务代码，没遇到什么太恶心的坑，就是理解业务逻辑费了点功夫。下个礼拜似乎又要开始撸组件撸网页了，现在想想感觉还是写写业务比较舒服，没事可以怼怼产品，给前端找找bug，写完还可以慢慢测；撸组件就比较无聊了，容易出大锅，而且还得求着人家用，用出问题还会被怼。。。不过好处大概就是以后跳槽面试的时候不容易被问死吧。。。

知识&技巧

常用@see和@link注释

写代码的时候经常会遇到一些需要枚举的类型，比如“活动类型”、“数据来源”这类的。但是一般来讲我们不会直接用enum类型，因为这些数据一般都是以整数的形式存储在数据表里面，因此用整型去存储、转移会更加方便。所以一般我们都是直接声明成一个整型，然后用另外一个类去存储这个类型的值，比如:

1
2

//需要引用的地方
int xxxType;

1
2
3
4
5
6

//该类型的值
public interface XxxType {
    int type1 = 1;
    int type2 = 2;
    int type3 = 3;
}

这样搞没啥问题，但是比较讨厌的就是，当另外一个人看到xxxType这个字段时，他可不知道这玩意的值是XxxType去记录的，他甚至有可能去用YyyType的类型去给xxxType赋值。这就说不清楚了。

因此一个比较简单的方法就是把注释写清楚了，而相比普通的注释，java的文档注释就比较好用了。这里面有一个@see的注释，非常适合这种场景：

1
2
3
4

/**
* @see the.package.of.XxxType
*/
int xxxType;

也可以使用{@link}注释，达到类似的效果:

1
2
3
4

/**
* {@link the.package.of.XxxType}
*/
int xxxType;

这样无论谁在给这个字段赋值时，都非常清楚的知道该赋什么值了。这一点jdk做的就非常好，要向他学习。。。

前言

好快啊，又是一周的轮回，本来打算把本周遇到的问题展开一个一个总结的，但是奈何踩的坑是在有点多，展开来根本没时间搞，索性就搞了这个类似周报的东西。希望从这一周开始，每一周都能坚持下来喽。

由于跟给老大看的周报不同，这个是给俺自己看的，所以成果啥的就不表了，主要表一表自己写的bug跟领悟。就记一些大实话吧，”写者有罪，闻者足戒“。

知识&技巧

while循环的控制逻辑写在循环体内

这句话是同事跟我讲的，领会了下他的意思，大概是，下面的写法二要比写法一好:

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

//Method1
while (!shouldBreak1() && !shouldBreak2()) {
    //Do sth
}

//Method1
while (true) {
    if (shouldBreak1()) {
        break;
    }
    if (shouldBreak2()) {
        break;
    }
    //Do sth
}

方法一看似简单清晰，一行代码就完成了控制逻辑，但是这样其实有弊端:

1. 调试麻烦，如果条件越来越多，容易混淆出错的到底是哪一行
2. 打日志不方便，这很显然
3. 逻辑一致性较差，有的控制逻辑可以写在开头，可有的控制逻辑就无法写在开头了，这时候不如都直接写在代码体里，保证一致性。

当然，复杂逻辑适合方法二这么搞，但是辩证的看，如果逻辑比较简单，用方法一也无可厚非嘛。

不要对数据表的记录进行物理删除

前言

前一段时间在做代码性能比较的时候用到了jmh这个工具，原本以为拥有了这个方便的工具就能hold住java微基准测试这个命题。但是事实上，用着用着就发现自己的理解还非常不深入，有很多在测试的时候难以解释的现象。于是查阅了相关资料，才发现这里面的水比我想象要深，趁着记忆还热乎，赶紧记录一下。

动态编译VS静态编译

java作为一种动态编译语言与c/c++这种静态编译语言有本质的不同。静态编译语言是在编译时就已经对代码做好了编译优化(比如C/C++在编译时指定-O1 -O2 -O3参数)，得到的程序能够直接被计算机忠实地执行。而java这种动态编译语言在编译时几乎不会做什么优化，而是等到运行在虚拟机中时，动态的进行优化。

动态优化有好处有坏处，好处就在于他可以根据程序实时的运行状况，忽略掉那些事实上没有被执行的代码的影响，最大化的优化那些被多次执行的代码（这也是jvm有“预热”这一说法的原因）；但是，缺点也在于，随着程序的运行，程序运行的环境会发生变化，如果继续保留之前动态优化的代码则会无法起作用甚至可能会出现错误，此时就需要卸载之前做的优化，这就是“动态反优化（Dynamic Deoptimization）”。

显然，我们并不希望jvm经常进行动态反优化，但是其实正常情况下，相比于程序逻辑的执行时间，这点反优化造成影响还是微不足道的。相比于他带来的问题，我们往往更加享受他带来的便利，因此大部分情况我们也无需太在意这些细节。但是当我们分析问题的粒度逐渐变小时、尤其是在做微基准测试时，就需要做到对这类问题心中有数了，否则就可能贻笑大方。

诡异的问题

说的可能有点玄乎，举一个简单的例子，比如下面这样一段微基准测试代码：

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

package com.pinduoduo.tusenpo.test;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5, time = 200, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 5, time = 200, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
@Threads(4)
@Fork(0)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class Test {

    private interface Operator {
        int operate(int d);
    }

    private class Method1 implements Operator {
        public int operate(int d) {
            return d + 1;
        }
    }

    private class Method2 implements Operator {
        public int operate(int d) {
            return d + 1;
        }
    }

    private void callMillionTimes(Operator op) {
        int d = 0;
        for (int i = 1; i < 1000000; i++)
            d = op.operate(d);
    }

    @Benchmark
    public void test_1_Method1() {
        callMillionTimes(new Method1());
    }

    @Benchmark
    public void test_2_Method2() {
        callMillionTimes(new Method2());
    }

    @Benchmark
    public void test_3_Empty() {
    }

    @Benchmark
    public void test_4_Method1Again() {
        callMillionTimes(new Method1());
    }

    @Benchmark
    public void test_5_NaiveLoop() {
        int d = 0;
        for (int i = 1; i < 1000000; i++)
            d = d + 1;
    }


    public static void main(String[] args) throws RunnerException, InterruptedException {
        new Runner(new OptionsBuilder().include(Test.class.getSimpleName()).build()).run();
    }
}

这段代码中我们定义了一个父类Operator和他的两个子类Method1、Method2，这两个类的实现完全相同，相当于一个自增操作。同时测试了五个方法：

1. test_1_Method1，将Method1的方法执行一百万次。
2. test_2_Method2，将Method2的方法执行一百万次。
3. test_3_Empty，这其实是一个空方法。
4. test_4_Method1Again，与test_1_Method1完全一样。
5. test_5_NaiveLoop，这个方法体现的是Method1和Method2的“本质”。