摘要：坑一慎用方法在類中，有一個(gè)方法是，返回的是一個(gè)數(shù)組，該數(shù)組包含了所包含的方法。坑二慎用線程優(yōu)先級(jí)做并發(fā)處理線程中有屬性，表示線程的優(yōu)先級(jí)，默認(rèn)值為，取值區(qū)間為。顯然，運(yùn)行時(shí)環(huán)境是因操作系統(tǒng)而異的。

本文為作者原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處。

我們都知道Java是跨平臺(tái)的，一次編譯，到處運(yùn)行，本質(zhì)上依賴于不同操作系統(tǒng)下有不同的JVM。到處運(yùn)行是做到了，但運(yùn)行結(jié)果呢？一樣的程序，在不同的JVM上跑的結(jié)果是否一樣呢？很遺憾，程序的執(zhí)行結(jié)果沒(méi)有百分百的確定性，本篇分享我遇到的一些case。

在Class類中，有一個(gè)方法是getMethods()，返回的是一個(gè)Method數(shù)組，該數(shù)組包含了Class所包含的方法。但是需要注意的是，其數(shù)組元素的排序是不確定的，在不同的機(jī)器上會(huì)有不一樣的排序輸出。

public Method[] getMethods() throws SecurityException {
    checkMemberAccess(Member.PUBLIC, Reflection.getCallerClass(), true);
    return copyMethods(privateGetPublicMethods());
}

阿里的fastjson就曾經(jīng)在這里踩到坑了，fastjson是序列化框架，當(dāng)要去獲取對(duì)象的某個(gè)屬性值時(shí)，往往需要通過(guò)反射調(diào)用getter方法。比如，有個(gè)屬性field，那么通過(guò)遍歷Method數(shù)組，判斷是否有g(shù)etField方法，如果有的話，則調(diào)用取得相應(yīng)的值。

但對(duì)于boolean類型的字段，其getter方法有可能是isXXX，也有可能是getXXX，而fastjson在遍歷時(shí)，只要判斷有isXXX或者getXXX，就認(rèn)定其為getter方法，然后立即執(zhí)行該getter方法。

// 偽代碼
for (Method method : someObject.class.getMethods()) {
    // 判斷是否為getter方法
    if(method.getName().equals("getField") || method.getName().equals("isField")){
        // 通過(guò)getter取得屬性值
        return method.invoke(xxx, xxxx);
    }
}

但是如果一個(gè)對(duì)象同時(shí)存在isA和getA方法呢？

private A a;

private boolan isA(){
    return false;
}

private A getA(){
    return a;
}

這個(gè)時(shí)候fastjson到底執(zhí)行的是isA()還是getA()呢？答案是不確定，因?yàn)閕sA和getA在返回的Method數(shù)組中順序是不確定的，所以有的機(jī)器上可能是通過(guò)isA()來(lái)獲取屬性值，有的機(jī)器上可能是通過(guò)getA()來(lái)獲取屬性值，而這兩個(gè)方法返回的一個(gè)是boolean類型，一個(gè)是A類型，導(dǎo)致fastjson在不同機(jī)器執(zhí)行的結(jié)果是不一樣的。

為什么這個(gè)方法返回值不按照字母排序呢？每個(gè)類或者方法名字都會(huì)對(duì)應(yīng)一個(gè)Symbol對(duì)象，在這個(gè)名字第一次使用的時(shí)候構(gòu)建，Symbol對(duì)象是通過(guò)malloc來(lái)分配的，因此新分配的Symbol對(duì)象的地址就不一定比后分配的Symbol對(duì)象地址小，也不一定大，因?yàn)槠陂g存在內(nèi)存free的動(dòng)作，那地址是不會(huì)一直線性變化的，之所以不按照字母排序，主要還是為了速度考慮，根據(jù)Symbol對(duì)象的地址排序是最快的。

線程Thread中有priority屬性，表示線程的優(yōu)先級(jí)，默認(rèn)值為5，取值區(qū)間為[1,10]。雖然在Thread的注釋中有說(shuō)明優(yōu)先級(jí)高的線程將會(huì)被優(yōu)先執(zhí)行，但是測(cè)試結(jié)果，卻是隨機(jī)的。

如下，

static class Runner implements Runnable {
    @Override
    public void run() {
        for (int i = 0; i < 100; i++) {
            System.out.println(Thread.currentThread().getName()+"---"+i);
        }
    }
}

public static void main(String[] args) {

    Thread t1 = new Thread(new Runner(), "thread-1");
    Thread t2 = new Thread(new Runner(), "thread-2");
    Thread t3 = new Thread(new Runner(), "thread-3");

    t1.setPriority(10); // t1 線程優(yōu)先級(jí)設(shè)置為10
    t2.setPriority(5);  // t2 線程優(yōu)先級(jí)設(shè)置為5
    t3.setPriority(1);  // t3 線程優(yōu)先級(jí)設(shè)置為1

    t1.start();
    t2.start();
    t3.start();
}

如果是嚴(yán)格按照線程優(yōu)先級(jí)來(lái)執(zhí)行的，那么應(yīng)該是t1執(zhí)行for循環(huán)，然后t2執(zhí)行完for循環(huán)，最后t3執(zhí)行for循環(huán)。但實(shí)際上測(cè)試結(jié)果顯示，每次執(zhí)行的輸出順序都沒(méi)有遵循這個(gè)規(guī)則，并且每次執(zhí)行的結(jié)果都是不一樣的。

---- console output ----
thread-2---0
thread-2---1
thread-3---0
thread-1---0
thread-1---1
thread-1---2
thread-3---1
......
......

線程調(diào)度具有很多不確定性，線程的優(yōu)先級(jí)只是對(duì)線程的一個(gè)標(biāo)志，但不代表著這是絕對(duì)的優(yōu)先，具體的執(zhí)行順序都是由操作系統(tǒng)本身的資源調(diào)度來(lái)決定的。不同操作系統(tǒng)本身的線程調(diào)度方式可能存在差異性，所以不能依靠線程優(yōu)先級(jí)來(lái)處理并發(fā)邏輯。

Java API中，一般使用native方法System.currentTimeMillis() 來(lái)獲取系統(tǒng)的時(shí)間。從方法名上，可以看出，該方法用于獲取系統(tǒng)當(dāng)前的時(shí)間，即從1970年1月1日8時(shí)到當(dāng)前的毫秒值。

下面羅列出了官方對(duì)該方法的注釋：

public final class System {
    /**
     * Note that while the unit of time of the return value is a millisecond,
     * the granularity of the value depends on the underlying
     * operating system and may be larger.  For example, many
     * operating systems measure time in units of tens of
     * milliseconds.
     */
    public static native long currentTimeMillis();
}

方法注釋明確指出了這個(gè)毫秒值的精度在不同的操作系統(tǒng)中是存在差異的，有的系統(tǒng)1毫秒實(shí)際上等同于物理時(shí)間的幾十毫秒。也就是說(shuō)，在一個(gè)性能測(cè)試中，因?yàn)榫炔灰恢碌膯?wèn)題，有的系統(tǒng)得出的結(jié)果是1毫秒，另外系統(tǒng)得出的性能結(jié)果卻是10毫秒。

那如何實(shí)現(xiàn)高精度的時(shí)間計(jì)算呢？先來(lái)看看System.nanoTime()方法，下面列出了官方的核心注釋：

public final class System {
    
    /**
    * This method can only be used to measure elapsed time and is
    * not related to any other notion of system or wall-clock time.
    */
    public static native long nanoTime();
}

這個(gè)方法只能用于檢測(cè)系統(tǒng)經(jīng)過(guò)的時(shí)間，也就是說(shuō)其返回的時(shí)間不是從1970年1月1日8時(shí)開(kāi)始的納秒時(shí)間，是從系統(tǒng)啟動(dòng)開(kāi)始時(shí)開(kāi)始計(jì)算的時(shí)間。

所以一般高精度的時(shí)間是采用System.nanoTime()方法來(lái)實(shí)現(xiàn)的，其單位為納秒（十億分之一秒），雖然不保證完全準(zhǔn)確的納秒級(jí)精度。但用該方法來(lái)實(shí)現(xiàn)毫秒級(jí)精度的計(jì)算，是綽綽有余的，如下。

 long start = System.nanoTime();
 // do something
 long end = System.nanoTime();
 
 // 程序執(zhí)行的時(shí)間，精確到毫秒
 long costTime = (end - start) / 1000000L

Runtime是JVM中運(yùn)行時(shí)環(huán)境的抽象，包含了運(yùn)行時(shí)環(huán)境的一些信息，每個(gè)Java應(yīng)用程序都有一個(gè)Runtime實(shí)例，用于應(yīng)用程序和其所在的運(yùn)行時(shí)環(huán)境進(jìn)行交互。應(yīng)用程序本身無(wú)法創(chuàng)建Runtime實(shí)例，只能通過(guò)Runtime.getRuntime()方法來(lái)獲取。

顯然，運(yùn)行時(shí)環(huán)境是因操作系統(tǒng)而異的。其交互方式也存在差異，
例如，

// Windows下調(diào)用程序
Process proc =Runtime.getRuntime().exec("exefile");
// Linux下調(diào)用程序
Process proc =Runtime.getRuntime().exec("./exefile");

所以，如果應(yīng)用程序中包含這類和運(yùn)行時(shí)環(huán)境進(jìn)行交互的方法，應(yīng)確保應(yīng)用的部署環(huán)境不變，如果不能保證的話，那么至少需要提供兩套運(yùn)行時(shí)交互邏輯。

以上是我遇到的不能跨平臺(tái)的一些case，其實(shí)本質(zhì)上都和native實(shí)現(xiàn)有關(guān)。你有沒(méi)有遇到一些這樣的坑呢？歡迎留言～

參考鏈接：
JVM源碼分析之不保證順序的Class.getMethods

公眾號(hào)簡(jiǎn)介：作者是螞蟻金服的一線開(kāi)發(fā)，分享自己的成長(zhǎng)和思考之路。內(nèi)容涉及數(shù)據(jù)、工程、算法。