java运行期的版本控制方案

2018-11-14

前言

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

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

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

方案

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

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

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

分析

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

more >>

展开全文 >>

TooSimple的工作周记（2）

2018-09-01

前言

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

知识&技巧

常用@see和@link注释

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

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

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

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

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

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

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

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

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

more >>

展开全文 >>

TooSimple的工作周记（1）

2018-08-25

前言

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

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

知识&技巧

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

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

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

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

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

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

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

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

more >>

展开全文 >>

从一个诡异的问题看JVM动态反优化

2018-08-11

前言

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

动态编译VS静态编译

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

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

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

诡异的问题

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

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，这两个类的实现完全相同，相当于一个自增操作。同时测试了五个方法：

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

more >>

展开全文 >>

字节数组转字符串技巧以及其jmh性能分析

2018-07-20

前言

前几天在面向 stackoverflow 编程时，遇到了一串有点诡异的代码:

private String method1(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte aByte : bytes) {
        sb.append(Integer.toString((aByte & 0xff) + 0x100, 16).substring(1));
    }
    return sb.toString();
}

对java还不是很熟，乍一看还是有点懵逼的，于是就抽了个时间研究了下。

分析

这段代码其实只做了一件简单的事，就是将一个字节数组转换成一个十六进制字符串，比如说传入{1,2,126,127,-1,-2,-127,-128}，就会输出01027e7ffffe8180。这种类似的代码在很多需要进行编码的场景下还是很常见的。

其实正常人在写这种功能的时候是这样写的：

private String method2(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte aByte : bytes) {
        sb.append(String.format("%02x", aByte));
    }
    return sb.toString();
}

这种代码还是比较好理解的，将一个byte转换成两个字节的十六进制字符串，通俗易懂。那method1是如何实现相同的功能的呢，这里有两个难点，理解了就简单了。

为什么要& 0xff
为什么要+ 0x100并且要substring(1)

第一点，是因为java中的byte是有符号的，为了使用Integer.toString()转换成16进制，必须要有一个从byte到int的转换。而默认的转换方法会保留符号，比如对于一个负数的byte，转换成int后符号位就提到最前面了，而我们期望的是无符号的转换。因此这里使用了& 0xff的方式，隐式的进行了无符号的转换。

第二点，是因为在byte转换为int后，在末8位的部分有可能是以0开头，这样转换成16进制后，生成的字符串长度就会小于2,开头的0就被舍弃了。因此我们通过+ 0x100的方式强制生成一个长度为3的字符串，再用substring(1)将开头的1舍弃，这样就保证了输出的字符串长度一定是2。

more >>

展开全文 >>