前言
最近看了極客時間的《Java業務開發常見錯誤100例》，再結合平時踩的一些代碼坑，寫寫總結，希望對大家有幫助，感謝閱讀~
1. 六類典型空指針問題
- 包裝類型的空指針問題
- 級聯調用的空指針問題
- Equals方法左邊的空指針問題
- ConcurrentHashMap 這樣的容器不支持 Key 和 Value 為 null。
- 集合，數組直接獲取元素
- 對象直接獲取屬性
1.1包裝類型的空指針問題
public class NullPointTest {
public static void main(String[] args) throws InterruptedException {
System.out.println(testInteger(null));
}
private static Integer testInteger(Integer i) {
return i + 1; //包裝類型，傳參可能為null，直接計算，則會導致空指針問題
}
}
1.2 級聯調用的空指針問題
public class NullPointTest {
public static void main(String[] args) {
//fruitService.getAppleService() 可能為空，會導致空指針問題
fruitService.getAppleService().getWeight().equals("OK");
}
}
1.3 Equals方法左邊的空指針問題
public class NullPointTest {
public static void main(String[] args) {
String s = null;
if (s.equals("666")) { //s可能為空，會導致空指針問題
System.out.println("公眾號：撿田螺的小男孩，666");
}
}
}
1.4 ConcurrentHashMap 這樣的容器不支持 Key，Value 為 null。
public class NullPointTest {
public static void main(String[] args) {
Map map = new ConcurrentHashMap<>();
String key = null;
String value = null;
map.put(key, value);
}
}
1.5 集合，數組直接獲取元素
public class NullPointTest {
public static void main(String[] args) {
int [] array=null;
List list = null;
System.out.println(array[0]); //空指針異常
System.out.println(list.get(0)); //空指針一場
}
}
1.6 對象直接獲取屬性
public class NullPointTest {
public static void main(String[] args) {
User user=null;
System.out.println(user.getAge()); //空指針異常
}
}
2. 日期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));
運行結果：
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));
3.金額數值計算精度的坑
看下這個浮點數計算的例子吧：
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.30000000000000004
0.19999999999999996
401.49999999999994
1.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.3000000000000000166533453693773481063544750213623046875
0.1999999999999999555910790149937383830547332763671875
401.49999999999996802557689079549163579940795898437500
1.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);
}
}
5. Integer緩存的坑
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:true
c==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;
}
7. 使用ThreadLocal，線程重用導致信息錯亂的坑
使用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();
}
}
8. 疏忽switch的return和break
這一點嚴格來說，應該不算坑，但是呢，大家寫代碼的時候，有些朋友容易疏忽了。直接看例子吧
/*
* 關注公眾號：
* 撿田螺的小男孩
*/
public class SwitchTest {
public static void main(String[] args) throws InterruptedException {
System.out.println("testSwitch結果是："+testSwitch("1"));
}
private static String testSwitch(String key) {
switch (key) {
case "1":
System.out.println("1");
case "2":
System.out.println(2);
return "2";
case "3":
System.out.println("3");
default:
System.out.println("返回默認值");
return "4";
}
}
}
輸出結果：
測試switch
1
2
testSwitch結果是：2
switch 是會沿着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());
}
}
運行結果：
1
Arrays.asList源碼如下：
public static <T> List<T> asList(T... a) {
return new ArrayList<>(a);
}
9.2 Arrays.asList 返回的 List 不支持增刪操作。
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的時候，對原始數組的修改會影響到我們獲得的那個List
public 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))包一下的。
10. ArrayList.toArray() 強轉的坑
public class ArrayListTest {
public static void main(String[] args) {
List<String> list = new ArrayList<String>(1);
list.add("公眾號：撿田螺的小男孩");
String[] array21 = (String[])list.toArray();//類型轉換異常
}
}
因為返回的是Object類型，Object類型數組強轉String數組，會發生ClassCastException。解決方案是，使用toArray()重載方法toArray(T[] a)
String[] array1 = list.toArray(new String[0]);//可以正常運行
11. 異常使用的幾個坑
11.1 不要弄丟了你的堆棧異常信息
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("系統忙請稍后再試");
}
}
11.2 不要把異常定義為靜態變量
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);
}
11.3 生產環境不要使用e.printStackTrace();
public void wrong(){
try {
readFile();
} catch (IOException e) {
//生產環境別用它
e.printStackTrace();
}
}
因為它占用太多內存，造成鎖死，並且，日志交錯混合，也不易讀。正確使用如下：
log.error("異常日志正常打印方式",e);
11.4 線程池提交過程中，出現異常怎么辦？
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);
}
}
}
12.JSON序列化,Long類型被轉成Integer類型！
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：true
java.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
}
});
}
IDE指定JVM參數：-Xmx8m -Xms8m :
運行結果：
我們看下源碼，其實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()按需讀取，當時讀取文件這些，一般是使用完需要關閉資源流的哈
15. 先查詢，再更新/刪除的並發一致性問題
再日常開發中，這種代碼實現經常可見：先查詢是否有剩余可用的票，再去更新票余量。
if(selectIsAvailable(ticketId){
1、deleteTicketById(ticketId)
2、給現金增加操作
}else{
return “沒有可用現金券”
}
如果是並發執行，很可能有問題的，應該利用數據庫更新/刪除的原子性，正解如下：
if(deleteAvailableTicketById(ticketId) == 1){
1、給現金增加操作
}else{
return “沒有可用現金券”
}
16. 數據庫使用utf-8存儲， 插入表情異常的坑
低版本的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住，那事務也是會失效呢~，偽代碼如下：
@Transactional
public void method(){
try{
//插入一條數據
insertA();
//更改一條數據
updateB();
}catch(Exception e){
logger.error("異常被捕獲了，那你的事務就失效咯",e);
}
}
18. 當反射遇到方法重載的坑
/**
* 反射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 =100
Integer grade =100
int grade =60
Integer grade =60
如果不通過反射，傳入Integer.valueOf(100)，走的是Integer重載。但是呢，反射不是根據入參類型確定方法重載的，而是以反射獲取方法時傳入的方法名稱和參數類型來確定的，正例如下：
getClass().getDeclaredMethod("score", Integer.class)
getClass().getDeclaredMethod("score", Integer.TYPE)
19. mysql 時間 timestamp的坑
有更新語句的時候，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