前言
最近結合平時踩的一些程式碼坑，寫寫總結，希望對大家有幫助，感謝閱讀~
反例：
Calendar calendar = Calendar.getInstance();calendar.set(2019, Calendar.DECEMBER, 31);Date testDate = calendar.getTime();SimpleDateFormat dtf = new SimpleDateFormat("YYYY-MM-dd");System.out.println("2019-12-31 轉 YYYY-MM-dd 格式後 " + dtf.format(testDate));執行結果：
2019-12-31 轉 YYYY-MM-dd 格式後 2020-12-31為什麼明明是2019年12月31號，就轉了一下格式，就變成了2020年12月31號了？因為YYYY是基於周來計算年的，它指向當天所在周屬於的年份，一週從週日開始算起，週六結束，只要本週跨年，那麼這一週就算下一年的了。正確姿勢是使用yyyy格式。
正例：
Calendar calendar = Calendar.getInstance();calendar.set(2019, Calendar.DECEMBER, 31);Date testDate = calendar.getTime();SimpleDateFormat dtf = new SimpleDateFormat("yyyy-MM-dd");System.out.println("2019-12-31 轉 yyyy-MM-dd 格式後 " + dtf.format(testDate));看下這個浮點數計算的例子吧：
public class DoubleTest { public static void main(String[] args) { System.out.println(0.1+0.2); System.out.println(1.0-0.8); System.out.println(4.015*100); System.out.println(123.3/100); double amount1 = 3.15; double amount2 = 2.10; if (amount1 - amount2 == 1.05){ System.out.println("OK"); } }}執行結果：
0.300000000000000040.19999999999999996401.499999999999941.2329999999999999可以發現，結算結果跟我們預期不一致，其實是因為計算機是以二進位制儲存數值的，對於浮點數也是。對於計算機而言，0.1無法精確表達，這就是為什麼浮點數會導致精確度缺失的。因此， 金額計算，一般都是用BigDecimal 型別
對於以上例子，我們改為BigDecimal，再看看執行效果：
System.out.println(new BigDecimal(0.1).add(new BigDecimal(0.2)));System.out.println(new BigDecimal(1.0).subtract(new BigDecimal(0.8)));System.out.println(new BigDecimal(4.015).multiply(new BigDecimal(100)));System.out.println(new BigDecimal(123.3).divide(new BigDecimal(100)));執行結果：
0.30000000000000001665334536937734810635447502136230468750.1999999999999999555910790149937383830547332763671875401.499999999999968025576890795491635799407958984375001.232999999999999971578290569595992565155029296875發現結果還是不對， 其實 ，使用 BigDecimal 表示和計算浮點數，必須使用 字串的構造方法來初始化 BigDecimal，正例如下：
public class DoubleTest { public static void main(String[] args) { System.out.println(new BigDecimal("0.1").add(new BigDecimal("0.2"))); System.out.println(new BigDecimal("1.0").subtract(new BigDecimal("0.8"))); System.out.println(new BigDecimal("4.015").multiply(new BigDecimal("100"))); System.out.println(new BigDecimal("123.3").divide(new BigDecimal("100"))); }}在進行金額計算，使用BigDecimal的時候，我們還需要 注意BigDecimal的幾位小數點，還有它的八種舍入模式哈 。
4. FileReader預設編碼導致亂碼問題看下這個例子：
public class FileReaderTest { public static void main(String[] args) throws IOException { Files.deleteIfExists(Paths.get("jay.txt")); Files.write(Paths.get("jay.txt"), "你好,撿田螺的小男孩".getBytes(Charset.forName("GBK"))); System.out.println("系統預設編碼："+Charset.defaultCharset()); char[] chars = new char[10]; String content = ""; try (FileReader fileReader = new FileReader("jay.txt")) { int count; while ((count = fileReader.read(chars)) != -1) { content += new String(chars, 0, count); } } System.out.println(content); }}執行結果：
系統預設編碼：UTF-8���,�����ݵ�С�к�從執行結果，可以知道，系統預設編碼是utf8，demo中讀取出來，出現亂碼了。為什麼呢？
FileReader 是以當 前機器的預設字符集 來讀取檔案的，如果希望指定字符集的話，需要直接使用 InputStreamReader 和 FileInputStream。
正例如下：
public class FileReaderTest { public static void main(String[] args) throws IOException { Files.deleteIfExists(Paths.get("jay.txt")); Files.write(Paths.get("jay.txt"), "你好,撿田螺的小男孩".getBytes(Charset.forName("GBK"))); System.out.println("系統預設編碼："+Charset.defaultCharset()); char[] chars = new char[10]; String content = ""; try (FileInputStream fileInputStream = new FileInputStream("jay.txt"); InputStreamReader inputStreamReader = new InputStreamReader(fileInputStream, Charset.forName("GBK"))) { int count; while ((count = inputStreamReader.read(chars)) != -1) { content += new String(chars, 0, count); } } System.out.println(content); }}public class IntegerTest { public static void main(String[] args) { Integer a = 127; Integer b = 127; System.out.println("a==b:"+ (a == b)); Integer c = 128; Integer d = 128; System.out.println("c==d:"+ (c == d)); }}執行結果：
a==b:truec==d:false為什麼Integer值如果是128就不相等了呢？ 編譯器會把 Integer a = 127 轉換為 Integer.valueOf(127)。 我們看下原始碼。
public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); }可以發現，i在一定範圍內，是會返回快取的。
預設情況下呢，這個快取區間就是[-128, 127]，所以我們業務日常開發中，如果涉及Integer值的比較，需要注意這個坑哈。還有呢，設定 JVM 引數加上 -XX:AutoBoxCacheMax=1000，是可以調整這個區間引數的，大家可以自己試一下哈
6. static靜態變數依賴spring例項化變數，可能導致初始化出錯之前看到過類似的程式碼。靜態變數依賴於spring容器的bean。
private static SmsService smsService = SpringContextUtils.getBean(SmsService.class);這個靜態的smsService有可能獲取不到的，因為類載入順序不是確定的，正確的寫法可以這樣，如下：
private static SmsService smsService =null; //使用到的時候採取獲取 public static SmsService getSmsService(){ if(smsService==null){ smsService = SpringContextUtils.getBean(SmsService.class); } return smsService; }使用ThreadLocal快取資訊，有可能出現資訊錯亂的情況。看下下面這個例子吧。
private static final ThreadLocal<Integer> currentUser = ThreadLocal.withInitial(() -> null);@GetMapping("wrong")public Map wrong(@RequestParam("userId") Integer userId) { //設定使用者資訊之前先查詢一次ThreadLocal中的使用者資訊 String before = Thread.currentThread().getName() + ":" + currentUser.get(); //設定使用者資訊到ThreadLocal currentUser.set(userId); //設定使用者資訊之後再查詢一次ThreadLocal中的使用者資訊 String after = Thread.currentThread().getName() + ":" + currentUser.get(); //彙總輸出兩次查詢結果 Map result = new HashMap(); result.put("before", before); result.put("after", after); return result;}按理說，每次獲取的before應該都是null，但是呢，程式執行在 Tomcat 中，執行程式的執行緒是 Tomcat 的工作執行緒，而 Tomcat 的工作執行緒是基於執行緒池的。
執行緒池會重用固定的幾個執行緒，一旦執行緒重用，那麼很可能首次從 ThreadLocal 獲取的值是之前其他使用者的請求遺留的值。這時，ThreadLocal 中的使用者資訊就是其他使用者的資訊。
把tomcat的工作執行緒設定為1
server.tomcat.max-threads=1使用者1，請求過來，會有以下結果，符合預期：
使用者2請求過來，會有以下結果， 不符合預期 ：
因此，使用類似 ThreadLocal 工具來存放一些資料時，需要特別注意在程式碼執行完後，顯式地去清空設定的資料，正例如下：
@GetMapping("right")public Map right(@RequestParam("userId") Integer userId) { String before = Thread.currentThread().getName() + ":" + currentUser.get(); currentUser.set(userId); try { String after = Thread.currentThread().getName() + ":" + currentUser.get(); Map result = new HashMap(); result.put("before", before); result.put("after", after); return result; } finally { //在finally程式碼塊中刪除ThreadLocal中的資料，確保資料不串 currentUser.remove(); }}這一點嚴格來說，應該不算坑，但是呢，大家寫程式碼的時候，有些朋友容易疏忽了。直接看例子吧
測試switch12testSwitch結果是：2switch 是會 沿著case一直往下匹配的，直到遇到return或者break。 所以，在寫程式碼的時候留意一下，是不是你要的結果。
9. Arrays.asList的幾個坑9.1 基本型別不能作為 Arrays.asList方法的引數，否則會被當做一個引數。public class ArrayAsListTest { public static void main(String[] args) { int[] array = {1, 2, 3}; List list = Arrays.asList(array); System.out.println(list.size()); }}執行結果：
Arrays.asList原始碼如下：
public static <T> List<T> asList(T... a) { return new ArrayList<>(a);}public class ArrayAsListTest { public static void main(String[] args) { String[] array = {"1", "2", "3"}; List list = Arrays.asList(array); list.add("5"); System.out.println(list.size()); }}執行結果：
Exception in thread "main" java.lang.UnsupportedOperationException at java.util.AbstractList.add(AbstractList.java:148) at java.util.AbstractList.add(AbstractList.java:108) at object.ArrayAsListTest.main(ArrayAsListTest.java:11)Arrays.asList 返回的 List 並不是我們期望的 java.util.ArrayList，而是 Arrays 的內部類 ArrayList。內部類的ArrayList沒有實現add方法，而是父類的add方法的實現，是會丟擲異常的呢。
9.3 使用Arrays.asLis的時候，對原始陣列的修改會影響到我們獲得的那個Listpublic class ArrayAsListTest { public static void main(String[] args) { String[] arr = {"1", "2", "3"}; List list = Arrays.asList(arr); arr[1] = "4"; System.out.println("原始陣列"+Arrays.toString(arr)); System.out.println("list陣列" + list); }}執行結果：
原始陣列[1, 4, 3]list陣列[1, 4, 3]從執行結果可以看到，原陣列改變，Arrays.asList轉化來的list也跟著改變啦，大家使用的時候要注意一下哦，可以用new ArrayList(Arrays.asList(arr))包一下的。
String[] array1 = list.toArray(new String[0]);//可以正常執行public void wrong1(){ try { readFile(); } catch (IOException e) { //沒有把異常e取出來，原始異常資訊丟失 throw new RuntimeException("系統忙請稍後再試"); }}public void wrong2(){ try { readFile(); } catch (IOException e) { //只保留了異常訊息，棧沒有記錄啦 log.error("檔案讀取錯誤, {}", e.getMessage()); throw new RuntimeException("系統忙請稍後再試"); }}正確的列印方式，應該醬紫
public void right(){ try { readFile(); } catch (IOException e) { //把整個IO異常都記錄下來，而不是隻列印訊息 log.error("檔案讀取錯誤", e); throw new RuntimeException("系統忙請稍後再試"); }}public void testStaticExeceptionOne{ try { exceptionOne(); } catch (Exception ex) { log.error("exception one error", ex); } try { exceptionTwo(); } catch (Exception ex) { log.error("exception two error", ex); }}private void exceptionOne() { //這裡有問題 throw Exceptions.ONEORTWO;}private void exceptionTwo() { //這裡有問題 throw Exceptions.ONEORTWO;}exceptionTwo丟擲的異常，很可能是 exceptionOne的異常哦。正確使用方法，應該是new 一個出來。
private void exceptionTwo() { throw new BusinessException("業務異常", 0001);}public void wrong(){ try { readFile(); } catch (IOException e) { //生產環境別用它 e.printStackTrace(); }}因為它佔用太多記憶體，造成鎖死，並且，日誌交錯混合，也不易讀。正確使用如下：
log.error("異常日誌正常列印方式",e);public class ThreadExceptionTest { public static void main(String[] args) { ExecutorService executorService = Executors.newFixedThreadPool(10); IntStream.rangeClosed(1, 10).forEach(i -> executorService.submit(()-> { if (i == 5) { System.out.println("發生異常啦"); throw new RuntimeException("error"); } System.out.println("當前執行第幾:" + Thread.currentThread().getName() ); } )); executorService.shutdown(); }}執行結果：
當前執行第幾:pool-1-thread-1當前執行第幾:pool-1-thread-2當前執行第幾:pool-1-thread-3當前執行第幾:pool-1-thread-4發生異常啦當前執行第幾:pool-1-thread-6當前執行第幾:pool-1-thread-7當前執行第幾:pool-1-thread-8當前執行第幾:pool-1-thread-9當前執行第幾:pool-1-thread-10可以發現，如果是使用submit方法提交到執行緒池的非同步任務，異常會被吞掉的，所以在日常發現中，如果會有可預見的異常，可以採取這幾種方案處理：
1.在任務程式碼try/catch捕獲異常2.透過Future物件的get方法接收丟擲的異常，再處理3.為工作者執行緒設定UncaughtExceptionHandler，在uncaughtException方法中處理異常4.重寫ThreadPoolExecutor的afterExecute方法，處理傳遞的異常引用11.5 finally重新丟擲的異常也要注意啦public void wrong() { try { log.info("try"); //異常丟失 throw new RuntimeException("try"); } finally { log.info("finally"); throw new RuntimeException("finally"); }}一個方法是不會出現兩個異常的呢，所以finally的異常會把try的 異常覆蓋 。正確的使用方式應該是，finally 程式碼塊 負責自己的異常捕獲和處理 。
public void right() { try { log.info("try"); throw new RuntimeException("try"); } finally { log.info("finally"); try { throw new RuntimeException("finally"); } catch (Exception ex) { log.error("finally", ex); } }}public class JSONTest { public static void main(String[] args) { Long idValue = 3000L; Map<String, Object> data = new HashMap<>(2); data.put("id", idValue); data.put("name", "撿田螺的小男孩"); Assert.assertEquals(idValue, (Long) data.get("id")); String jsonString = JSON.toJSONString(data); // 反序列化時Long被轉為了Integer Map map = JSON.parseObject(jsonString, Map.class); Object idObj = map.get("id"); System.out.println("反序列化的型別是否為Integer："+(idObj instanceof Integer)); Assert.assertEquals(idValue, (Long) idObj); }}Exception in thread "main" 反序列化的型別是否為Integer：truejava.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long at object.JSONTest.main(JSONTest.java:24)注意啦，序列化為Json串後，Josn串是沒有Long型別呢。而且反序列化回來如果也是Object接收，數字小於Interger最大值的話，給轉成Integer啦！
13. 使用Executors宣告執行緒池，newFixedThreadPool的OOM問題ExecutorService executor = Executors.newFixedThreadPool(10); for (int i = 0; i < Integer.MAX_VALUE; i++) { executor.execute(() -> { try { Thread.sleep(10000); } catch (InterruptedException e) { //do nothing } }); }執行結果：
我們看下原始碼，其實newFixedThreadPool使用的是無界佇列！
public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());}public class LinkedBlockingQueue<E> extends AbstractQueue<E> implements BlockingQueue<E>, java.io.Serializable { ... /** * Creates a {@code LinkedBlockingQueue} with a capacity of * {@link Integer#MAX_VALUE}. */ public LinkedBlockingQueue() { this(Integer.MAX_VALUE); }...}newFixedThreadPool執行緒池的核心執行緒數是固定的，它使用了近乎於無界的LinkedBlockingQueue阻塞佇列。當核心執行緒用完後，任務會入隊到阻塞佇列，如果任務執行的時間比較長，沒有釋放，會導致越來越多的任務堆積到阻塞佇列，最後導致機器的記憶體使用不停的飆升，造成JVM OOM。
14. 直接大檔案或者一次性從資料庫讀取太多資料到記憶體，可能導致OOM問題如果一次性把大檔案或者資料庫太多資料達到記憶體，是會導致OOM的。所以，為什麼查詢DB資料庫，一般都建議分批。
讀取檔案的話，一般問檔案不會太大，才使用 Files.readAllLines() 。為什麼呢？因為它是直接把檔案都讀到記憶體的，預估下不會OOM才使用這個吧，可以看下它的原始碼：
public static List<String> readAllLines(Path path, Charset cs) throws IOException { try (BufferedReader reader = newBufferedReader(path, cs)) { List<String> result = new ArrayList<>(); for (;;) { String line = reader.readLine(); if (line == null) break; result.add(line); } return result; }}如果是太大的檔案，可以使用Files.line()按需讀取，當時讀取檔案這些，一般是使用完需要 關閉資源流 的哈
if(selectIsAvailable(ticketId){ 1、deleteTicketById(ticketId) 2、給現金增加操作 }else{ return “沒有可用現金券” }如果是併發執行，很可能有問題的，應該利用資料庫更新/刪除的原子性，正解如下：
if(deleteAvailableTicketById(ticketId) == 1){ 1、給現金增加操作 }else{ return “沒有可用現金券” }低版本的MySQL支援的utf8編碼，最大字元長度為 3 位元組，但是呢，儲存表情需要4個位元組，因此如果用utf8儲存表情的話，會報 SQLException: Incorrect string value: '\xF0\x9F\x98\x84' for column ，所以一般用utf8mb4編碼去儲存表情。
17. 事務未生效的坑日常業務開發中，我們經常跟事務打交道， 事務失效 主要有以下幾個場景：
底層資料庫引擎不支援事務在非public修飾的方法使用rollbackFor屬性設定錯誤本類方法直接呼叫異常被try...catch吃了，導致事務失效。其中，最容易踩的坑就是後面兩個， 註解的事務方法給本類方法直接呼叫 ，虛擬碼如下：
public class TransactionTest{ public void A(){ //插入一條資料 //呼叫方法B (本地的類呼叫，事務失效了) B(); } @Transactional public void B(){ //插入資料 }}如果用異常catch住， 那事務也是會失效呢 ~，虛擬碼如下：
@Transactionalpublic void method(){ try{ //插入一條資料 insertA(); //更改一條資料 updateB(); }catch(Exception e){ logger.error("異常被捕獲了，那你的事務就失效咯",e); }}/** * 反射demo * @author 撿田螺的小男孩 */public class ReflectionTest { private void score(int score) { System.out.println("int grade =" + score); } private void score(Integer score) { System.out.println("Integer grade =" + score); } public static void main(String[] args) throws Exception { ReflectionTest reflectionTest = new ReflectionTest(); reflectionTest.score(100); reflectionTest.score(Integer.valueOf(100)); reflectionTest.getClass().getDeclaredMethod("score", Integer.TYPE).invoke(reflectionTest, Integer.valueOf("60")); reflectionTest.getClass().getDeclaredMethod("score", Integer.class).invoke(reflectionTest, Integer.valueOf("60")); }}執行結果：
int grade =100Integer grade =100int grade =60Integer grade =60如果 不透過反射 ，傳入 Integer.valueOf(100) ，走的是Integer過載。但是呢，反射不是根據入參型別確定方法過載的，而是 以反射獲取方法時傳入的方法名稱和引數型別來確定 的，正例如下：
getClass().getDeclaredMethod("score", Integer.class)getClass().getDeclaredMethod("score", Integer.TYPE)在更新語句的時候，timestamp可能會自動更新為當前時間，看個demo
CREATE TABLE `t` ( `a` int(11) DEFAULT NULL, `b` timestamp NOT NULL, `c` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) ENGINE=InnoDB DEFAULT CHARSET=utf8我們可以發現 c列 是有 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ，所以c列會隨著記錄更新而 更新為當前時間 。但是b列也會隨著有記錄更新為而 更新為當前時間 。
可以使用datetime代替它,需要更新為當前時間，就把 now() 賦值進來，或者修改mysql的這個引數 explicit_defaults_for_timestamp 。
20. mysql8資料庫的時區坑之前我們對mysql資料庫進行升級，新版本為8.0.12。但是升級完之後，發現now()函式，獲取到的時間比北京時間早8小時，原來是因為mysql8預設為美國那邊的時間，需要指定下時區
jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai原文連結： http://www.cnblogs.com/jay-huaxiao/p/14198000.html