起因
臨下班，偶然看到阿里巴巴《JAVA開發手冊》中，關於整型包裝類對象之間值的比較的規約，裏面提到強制使用equals,而不使用==。原因衆所周知，在-128 至 127，Integer 對象是在 IntegerCache.cache 產生。
所以很多人會在代碼裏使用去進行-128 至 127之間的數值比較。特別是一些常量，如state,status這類的常量，值通常都在100以內進行定義。感覺上是沒有問題。阿里的《JAVA開發手冊》裏面也提到了“**這個區間內的 Integer 值可以直接使用進行判斷**”。
但是，搞大數據的同學請注意了！
大數據天然是分佈式的，比如spark,每個executor執行器哪怕在同一個服務器節點上，也會申請一個單獨的JVM,所以，這個時候定義一個Integer哪怕是落在-128 至 127範圍以內，通過“==”能得到想要的效果嗎？
都在不同的JVM了，內存地址當然不一樣了，所以答案很顯然是否定的。
動機
鑑於阿里巴巴的影響力，它的《JAVA開發手冊》讀者還有衆多的。所以，覺得有必要提醒出這一點。
1.在大數據分佈式情況下，對於 Integer var = ? 在-128 至 127 之間的賦值，不可以直接使用==進行判斷。
2.不管是單機程序還是分佈式程序，一律使用equals進行數值比較，或者使用基礎數據類型。
驗證
測試代碼：
public class Constants {
public static final Integer STATE = 1;
}
int state = 1;
Integer state1 = 1;
Integer state2 = new Integer(1);
Integer state3 = Integer.valueOf(1);
SparkSession session = SparkSession.builder().appName("Validate").getOrCreate();
Long count = session.read().limf("/patt").select("vin").map(new MapFunction<Row, String>() {
@Override
public String call(Row value) throws Exception {
System.out.println("1 hashcode :" + System.identityHashCode(state1)+" 2:"+System.identityHashCode(state2)+" 3:"+System.identityHashCode(state3)+" constant = " + System.identityHashCode(Constants.STATE.hashCode()));
System.out.println((state == Constants.STATE) + " 1:" + (state1 == Constants.STATE) + " 2:" + (state2 == Constants.STATE) + " 3:" + (state3 == Constants.STATE));
Thread.sleep(100000);
return value.mkString();
}
}, Encoders.STRING()).count();
在不同的task打印出來的日誌：
可以看到，用了Integer包裝類的分佈式內部比較使用“==”得不到預期值。
處理
已在github提出問題
https://github.com/alibaba/p3c/issues/863