這些Java8官方挖過的坑，你踩過幾個？
導讀：系統啓動異常日誌竟然被JDK吞噬無法定位？同樣的加密方法，竟然出現部分數據解密失敗？往List裏面添加數據竟然提示不支持？日期明明間隔1年卻輸出1天，難不成這是天上人間？1582年神祕消失的10天JDK能否識別？Stream很高大上，List轉Map卻全失敗……這些JDK8官方挖的坑，你踩過幾個？ 關注公衆號【碼大叔】，實戰踩坑硬核分享，一起交流！
@
目錄
一、Base64：你是我解不開的迷
二、被吞噬的異常：我不敢說出你的名字
三、日期計算：我想留住時間，讓1天像1年那麼長
四、List：一如你我初見，不增不減
五、Stream處理：給你，獨一無二
六、結尾：紙上得來終覺淺，絕知此事要躬行！
推薦閱讀
一、Base64：你是我解不開的迷
出於用戶隱私信息保護的目的，系統上需將姓名、身份證、手機號等敏感信息進行加密存儲，很自然選擇了AES算法，外面又套了一層Base64，之前用的是sun.misc.BASE64Decoder/BASE64Encoder，網上的資料基本也都是這種寫法，運行得很完美。但這種寫法在idea或者maven編譯時就會有一些黃色告警提示。到了Java 8後，Base64編碼已經成爲Java類庫的標準，內置了 Base64 編碼的編碼器和解碼器。於是乎，我手賤地修改了代碼，改用了jdk8自帶的Base64方法
import java.util.Base64;
public class Base64Utils {
public static final Base64.Decoder DECODER = Base64.getDecoder();
public static final Base64.Encoder ENCODER = Base64.getDecoder();
public static String encodeToString(byte[] textByte) {
return ENCODER.encodeToString(textByte);
}
public static byte[] decode(String str) {
return DECODER.decode(str);
}
}
程序員的職業操守咱還是有的，構造新老數據、自測、通過，提交測試版本。信心滿滿，我要繼續延續我 0 Bug的神話！然後……然後版本就被打回了。
Caused by: java.lang.IllegalArgumentException: Illegal base64 character 3f
at java.util.Base64$Decoder.decode0(Base64.java:714)
at java.util.Base64$Decoder.decode(Base64.java:526)
at java.util.Base64$Decoder.decode(Base64.java:549)關鍵是這個錯還很詭異，部分數據是可以解密的，部分解不開。
Base64依賴於簡單的編碼和解碼算法，使用65個字符的US-ASCII子集，其中前64個字符中的每一個都映射到等效的6位二進制序列，第65個字符（=）用於將Base64編碼的文本填充到整數大小。後來產生了3個變種：
RFC 4648：Basic
此變體使用RFC 4648和RFC 2045的Base64字母表進行編碼和解碼。編碼器將編碼的輸出流視爲一行; 沒有輸出行分隔符。解碼器拒絕包含Base64字母表之外的字符的編碼。
RFC 2045：MIME
此變體使用RFC 2045提供的Base64字母表進行編碼和解碼。編碼的輸出流被組織成不超過76個字符的行; 每行（最後一行除外）通過行分隔符與下一行分隔。解碼期間將忽略Base64字母表中未找到的所有行分隔符或其他字符。
RFC 4648：Url
此變體使用RFC 4648中提供的Base64字母表進行編碼和解碼。字母表與前面顯示的字母相同，只是-替換+和_替換/。不輸出行分隔符。解碼器拒絕包含Base64字母表之外的字符的編碼。
S.N. 方法名稱 & 描述
1 static Base64.Decoder getDecoder()
返回Base64.Decoder解碼使用基本型base64編碼方案。
2 static Base64.Encoder getEncoder()
返回Base64.Encoder編碼使用的基本型base64編碼方案。
3 static Base64.Decoder getMimeDecoder()
返回Base64.Decoder解碼使用MIME類型的base64解碼方案。
4 static Base64.Encoder getMimeEncoder()
返回Base64.Encoder編碼使用MIME類型base64編碼方案。
5 static Base64.Encoder getMimeEncoder(int lineLength, byte[] lineSeparator)
返回Base64.Encoder編碼使用指定的行長度和線分隔的MIME類型base64編碼方案。
6 static Base64.Decoder getUrlDecoder()
返回Base64.Decoder解碼使用URL和文件名安全型base64編碼方案。
7 static Base64.Encoder getUrlEncoder()
返回Base64.Decoder解碼使用URL和文件名安全型base64編碼方案。
關於base64用法的詳細說明，可參考：https://juejin.im/post/5c99b2976fb9a070e76376cc
對於上面的錯誤，網上有的說法是，建議使用Base64.getMimeDecoder()和Base64.getMimeEncoder()，對此我只能建議：老的系統如果已經有數據了，就不要使用jdk自帶的Base64了。JDK官方的Base64和sun的base64是不兼容的！不要替換！不要替換！不要替換！
二、被吞噬的異常：我不敢說出你的名字
這個問題理解起來還是蠻費腦子的，所以我把這個系統異常發生的過程提煉成了一個美好的故事，放鬆一下，吟詩一首！
最怕相思濃
一切皆是你
唯獨
不敢說出你的名字
-- 碼大叔
這個問題是在使用springboot的註解時遇到的問題，發現JDK在解析註解時，若註解依賴的類定義在JVM加載時不存在，也就是NoClassDefFoundError時，實際拿到的異常將會是ArrayStoreException，而不是NoClassDefFoundError，涉及到的JDK裏的類是AnnotationParser.java, 具體代碼如下：
private static Object parseClassArray(int paramInt, ByteBuffer paramByteBuffer, ConstantPool paramConstantPool, Class<?> paramClass) {
Class[] arrayOfClass = new Class[paramInt];
int i = 0;
int j = 0;
for (int k = 0; k < paramInt; k++){
j = paramByteBuffer.get();
if (j == 99) {
// 注意這個方法
arrayOfClass[k] = parseClassValue(paramByteBuffer, paramConstantPool, paramClass);
} else {
skipMemberValue(j, paramByteBuffer);
i = 1;
}
}
return i != 0 ? exceptionProxy(j) : arrayOfClass;}
private static Object parseClassValue(ByteBuffer paramByteBuffer, ConstantPool paramConstantPool, Class<?> paramClass) {
int i = paramByteBuffer.getShort() & 0xFFFF;
try
{
String str = paramConstantPool.getUTF8At(i);
return parseSig(str, paramClass);
} catch (IllegalArgumentException localIllegalArgumentException) {
return paramConstantPool.getClassAt(i);
} catch (NoClassDefFoundError localNoClassDefFoundError) {
// 注意這裏，異常發生了轉化
return new TypeNotPresentExceptionProxy("[unknown]", localNoClassDefFoundError);
} catch (TypeNotPresentException localTypeNotPresentException) {
return new TypeNotPresentExceptionProxy(localTypeNotPresentException.typeName(), localTypeNotPresentException.getCause());
}}
在 parseClassArray這個方法中，預期parseClassValue返回Class對象，但看實際parseClassValue的邏輯，在遇到NoClassDefFoundError時，返回的是TypeNotPresentExceptionProxy，由於類型強轉失敗，最終拋出的是java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy，此時只能通過debug到這行代碼，找到具體是缺少哪個類定義，才能解決這個問題。
筆者重現一下發現這個坑的場景，有三個module，module3依賴module2但未聲明依賴module1，module2依賴module1，但聲明的是optional類型，依賴關係圖如下：
上面每個module中有一個Class，我們命名爲ClassInModuleX。ClassInModule3啓動時在註解中使用了ClassInModule2的類，而ClassInModule2這個類的繼承了ClassInModule1，這幾個類的依賴關係圖如下：
如此，其實很容易知道在module運行ClassInModule3時，會出現ClassInModule1的NoClassDefFoundError的，但實際運行時，你能看到的異常將不是NoClassDefFoundError，而是java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy，此時，若想要知道具體是何許異常，需通過debug在AnnotationParser中定位具體問題，以下展示兩個截圖，分別對應系統控制檯實際拋出的異常和通過debug發現的異常信息。
控制檯異常信息：
注意異常實際在紅色圈圈這裏，自動收縮了，需要展開纔可以看到通過debug發現的異常信息：
如果你想體驗這個示例，可關注公衆號碼大叔和筆者交流。如果你下次遇到莫名的java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy,請記得用這個方法定位具體問題。
三、日期計算：我想留住時間，讓1天像1年那麼長
Java8之前日期時間操作相當地麻煩，無論是Calendar還是SimpleDateFormat都讓你覺得這個設計怎麼如此地反人類，甚至還會出現多線程安全的問題，阿里巴巴開發手冊中就曾禁用static修飾SimpleDateFormat。好在千呼萬喚之後，使出來了，Java8帶來了全新的日期和時間API，還帶來了Period和Duration用於時間日期計算的兩個API。
Duraction和Period，都表示一段時間的間隔，Duraction正常用來表示時、分、秒甚至納秒之間的時間間隔，Period正常用於年、月、日之間的時間間隔。
網上的大部分文章也是這麼描述的，於是計算兩個日期間隔可以寫成下面這樣的代碼：
// parseToDate方法作用是將String轉爲LocalDate，略。
LocalDate date1 = parseToDate("2020-05-12");
LocalDate date2 = parseToDate("2021-05-13");
// 計算日期間隔
int period = Period.between(date1,date2).getDays();
一個是2020年，一個是2021年，你認爲間隔是多少？1年?
恭喜你，和我一起跳進坑裏了（畫外音：裏面的都擠一擠，動一動，又來新人了）。
正確答案應該是：1天。
這個單詞的含義以及這個方法看起來確實是蠻誤導人的，一不注意就會掉進坑裏。Period其實只能計算同月的天數、同年的月數，不能計算跨月的天數以及跨年的月數。
正確寫法1：
long period = date2.toEpochDay()-date1.toEpochDay();
toEpochDay()：將日期轉換成Epoch 天，也就是相對於1970-01-01（ISO）開始的天數，和時間戳是一個道理，時間戳是秒數。顯然，該方法是有一定的侷限性的。
正確寫法2：
long period = date1.until(date2,ChronoUnit.DAYS);
使用這個寫法，一定要注意一下date1和date2前後順序：date1 until date2。
正確做法3（推薦）：
long period = ChronoUnit.DAYS.between(date1, date2);
ChronoUnit：一組標準的日期時間單位。這組單元提供基於單元的訪問來操縱日期，時間或日期時間。 這些單元適用於多個日曆系統。這是一個最終的、不可變的和線程安全的枚舉。
看到”適用於多個日曆系統“這句話，我一下子想起來歷史上1582年神祕消失的10天，在JDK8上是什麼效果呢？1582-10-15和1582-10-04你覺得會相隔幾天呢？11天還是1天？有興趣的小夥伴自己去寫個代碼試試吧。
打開你的手機，跳轉到1582年10月，你就能看到這消失的10天了。
四、List：一如你我初見，不增不減
這個問題其實在JDK裏存在很多年了，JDK8中依然存在，也是很多人最容易跳的一個坑！直接上代碼：
public List allUser() {
// 省略
List<String> currentUserList = getUser();
currentUserList.add("碼大叔");
// 省略}
就是上面這樣一段代碼，往一個list裏添加一條數據，你覺得結果是什麼呢？“碼大叔”成功地添加到了List裏？天真，不報個錯你怎麼能意識到JDK存在呢。
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)原因：
因爲在getUser方法裏，返回的List使用的是Arrays.asList生成的，示例：
private List<String> getUser(){
return Arrays.asList("劍聖","小九九");
}我們來看看Arrays.asList的源碼
@SafeVarargs
@SuppressWarnings("varargs")
public static <T> List<T> asList(T... a) {
return new ArrayList<>(a);
}private static class ArrayList extends AbstractList
implements RandomAccess, java.io.Serializable
{
private final E[] a;
// 部分代碼略
ArrayList(E[] array) {
// 返回的是一個定長的數組
a = Objects.requireNonNull(array);
}
// 部分代碼略}
很明顯，返回的實際是一個定長的數組，所以只能“一如你我初見”，初始化什麼樣子就什麼樣子，不能新增，不能減少。如果你理解了，那我們就再來一個栗子
int[] intArr = {1,2,3,4,5};
Integer[] integerArr = {1,2,3,4,5};
String[] strArr = {"1", "2", "3", "4", "5"};
List list1 = Arrays.asList(intArr);
List list2 = Arrays.asList(integerArr);
List list3 = Arrays.asList(strArr);
System.out.println("list1中的數量是：" + list1.size());
System.out.println("list2中的數量是：" + list2.size());
System.out.println("list3中的數量是：" + list3.size());
你覺得答案是什麼？預想3秒鐘，揭曉答案，看跟你預想的是否一致呢？
list1中的數量是：1
list2中的數量是：5
list3中的數量是：5
是不是和你預想又不一樣了？還是回到Arrays.asList方法，該方法的輸入只能是一個泛型變長參數。基本類型是不能泛型化的，也就是說8個基本類型不能作爲泛型參數，要想作爲泛型參數就必須使用其所對應的包裝類型，那前面的例子傳遞了一個int類型的數組，爲何程序沒有報編譯錯誤呢？在Java中，數組是一個對象，它是可以泛型化的，也就是說我們的例子是把一個int類型的數組作爲了T的類型，所以在轉換後在List中就只有1個類型爲int數組的元素了。除了int，其它7個基本類型的數組也存在相似的問題。
JDK裏還爲我們提供了一個便捷的集合操作工具類Collections，比如多個List合併時，可以使用Collections.addAll(list1,list2), 在使用時也同樣要時刻提醒自己：“請勿踩坑”！
五、Stream處理：給你，獨一無二
Java8中新增了Stream流 ，通過流我們能夠對集合中的每個元素進行一系列並行或串行的流水線操作。當使用一個流的時候，通常包括三個基本步驟：獲取一個數據源（source）→ 數據轉換→執行操作獲取想要的結 果，每次轉換原有 Stream 對象不改變，返回一個新的 Stream 對象（可以有多次轉換），這就允許對其操作可以 像鏈條一樣排列，變成一個管道。
項目上千萬不要使用Stream，因爲一旦用起來你會覺得真屏蔽詞爽，根本停不下來。當然不可避免的，還是有一些小坑的。
假設我們分析用戶的訪問日誌，放到list裏。
list.add(new User("碼大叔", "登錄公衆號"));
list.add(new User("碼大叔", "編寫文章"));
因爲一些原因，我們要講list轉爲map，Steam走起來，
private static void convert2MapByStream(List list) {
Map<String, String> map = list.stream().collect(Collectors.toMap(User::getName, User::getValue));
System.out.println(map);}
咣噹，掉坑裏了，程序將拋出異常：
Exception in thread "main" java.lang.IllegalStateException: Duplicate key 碼大叔
使用Collectors.toMap() 方法中時，默認key值是不允許重複的。當然，該方法還提供了第三個參數：也就是出現 duplicate key的時候的處理方案
如果在開發的時候就考慮到了key可能重複，你需要在這樣定義convert2MapByStream方法，聲明在遇到重複key時是使用新值還是原有值：
private static void convert2MapByStream(List<User> list) {
Map<String, String> map = list.stream().collect(Collectors.toMap(User::getName, User::getValue, (oldVal, newVal) -> newVal));
System.out.println(map);
}關於Stream的坑其實還是蠻多的，比如尋找list中的某個對象，可以使用findAny().get(),你以爲是找到就返回找不到就就返回null？依然天真，找不到會拋出異常的，需要使用額外的orElse方法。
六、結尾：紙上得來終覺淺，絕知此事要躬行！
所謂JDK官方的坑，基本上都是因爲我們對技術點了解的不夠深入，望文生義，以爲是怎樣怎樣的，而實際上我們的自以爲是讓我們掉進了一個又一個坑裏。面對着這些坑，我流下了學藝不精的眼淚！但也有些坑，確實發生的莫名其妙，比如吞噬異常，沒有理解JDK爲什麼這麼設計。還有些坑，誤導性確實太強了，比如日期計算、list操作等。最後只能說一句：
紙上得來終覺淺，絕知此事要躬行！
編碼不易，且行且珍惜！