Java日常開發的21個坑,你踩過幾個?

2021-02-13 我是程序汪
前言

最近看了極客時間的《Java業務開發常見錯誤100例》,再結合平時踩的一些代碼坑,寫寫總結,希望對大家有幫助,感謝閱讀~

1. 六類典型空指針問題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方法提交到線程池的異步任務,異常會被吞掉的,所以在日常發現中,如果會有可預見的異常,可以採取這幾種方案處理:

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 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

參考與感謝[1]

Java業務開發常見錯誤100例: https://time.geekbang.org/column/article/220230

相關焦點

  • Java 日常開發的 21 個坑
    日期YYYY格式設置的坑日常開發,經常需要對日期格式化,但是呢,年份設置為YYYY大寫的時候,是有坑的哦。❝默認情況下呢,這個緩存區間就是[-128, 127],所以我們業務日常開發中,如果涉及Integer值的比較,需要注意這個坑哈。
  • Java 開發中如何正確踩坑
    你要找到最好的人,一個好的工程師不是頂10個,是頂100個。所以,在核心工程師上面,大家一定要不惜血本去找,千萬不要想偷懶只用培養大學生的方法去做。最好的人本身有很強的驅動力,你只要把他放到他喜歡的事情上,讓他自己有玩的心態,他才能真正做出一些事情,打動他自己,才能打動別人。所以你今天看到我們很多的工程師,他自己在邊玩邊創新。所以,找最好的人,要給他做他喜歡和擅長的事情。
  • 編程中的21個坑,你佔幾個?
    前言最近看了某客時間的《Java業務開發常見錯誤100例》,再結合平時踩的一些代碼坑,寫寫總結,希望對大家有幫助,感謝閱讀~1. 六類典型空指針問題ConcurrentHashMap 這樣的容器不支持 Key 和 Value 為 null。
  • 一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!|原創
    既然天天在用,那就沒準就會踩中這幾個 List 常見坑。今天我們就來總結這些常見的坑在哪裡,撈自己一手,防止後續同學再繼續踩坑。本文設計知識點如下:List 踩坑大全ArrayList 這是李逵,還是李鬼?以前實習的時候,寫過這樣一段簡單代碼,通過 Arrays#asList 將數組轉化為 List 集合。
  • 幾百家網店失敗總結 做電商最容易踩的49個坑
    小舟前言: 常說坑爹啊,其實很多時候,這個「坑」也是咱們自己不小心,或者自己不知不覺給挖的,但如果你提前防範
  • Java 序列化的這三個坑千萬要小心
    /dev-guide/images/dubbo-extension.jpg圖片來源:https://dubbo.apache.org/zh/docs/v2.7/dev/design/從Dubbo的調用鏈可以發現是有一個序列化節點的,其支持的序列化協議一共有四種:dubbo序列化:阿里尚未開發成熟的高效
  • Java序列化的這三個坑你可千萬要小心,別又掉進去了~
    dev-guide/images/dubbo-extension.jpg圖片來源:https://dubbo.apache.org/zh/docs/v2.7/dev/design/從Dubbo的調用鏈可以發現是有一個序列化節點的,其支持的序列化協議一共有四種:dubbo序列化:阿里尚未開發成熟的高效
  • 踩過 ArrayList 這幾個坑的請舉手
    他:異常信息是 java.lang.UnsupportedOperationException,是調用 add 方法時拋出的。恩,我大概明白了,這可能是 ArrayList的又一個坑,和 subList應該有異曲同工之妙。
  • 這些年你踩過多少桶裝啤酒的坑
    這些年你踩過多少桶裝啤酒的坑  開啟避
  • 萬能的Java開發過的7個經典遊戲,你玩過幾個?
    相信很多剛接觸編程的同學,對於Java開發能做些什麼、做過哪些遊戲,並不是特別清楚。
  • Java中七個潛在的內存洩露風險,你知道幾個?
    類,並讓java.lang.ref.Finalizer持有這個類的引用,在上文中的例子中,因為Finalizer類的引用被java.lang.ref.Finalizer持有,所以他的實例並不能被Young GC清理,反而會轉入到老年代。
  • 【都給你總結好了!】你必須掌握的 21 個 Java 核心技術!
    為什麼強調要知道這個呢,知道了java最純粹的啟動方式之後,你才能在啟動出問題的時候,去分析當時啟動的目錄多少,執行命名如何,參數如何,是否有缺失等。這樣有利於你真正開發中去解決那些奇奇怪怪的可能和環境相關的問題。java 命令的使用, 帶package的java類如何在命令行中啟動java程序涉及到的各個路徑(classpath, java。library。
  • Java 開發中如何正確的踩坑
    為什麼說一個好的員工能頂 100 個普通員工?我們的做法是,要用最好的人。我一直都認為研發本身是很有創造性的,如果人不放鬆,或不夠聰明,都很難做得好。你要找到最好的人,一個好的工程師不是頂10個,是頂100個。所以,在核心工程師上面,大家一定要不惜血本去找,千萬不要想偷懶只用培養大學生的方法去做。
  • 反相輸入放大器與生俱來的坑,你踩過沒有?
    首先自問自答,下文提到的這個坑,我真的踩過,很丟臉,還不止一次。下面具體講講。我們都知道反相放大器能將輸入的信號反相放大,這是很基本的知識,學過電路的一般都知道。反相放大器的公式為Vout=-Vin*Rf/Rin.根據已知的公式,能很輕鬆的完成設計,但反相放大器與生俱來的有個小缺陷,反相輸入放大器的輸入阻抗不是很高,而我們在電路設計中一般希望放大器的輸入阻抗要高,這樣放大器才不會從信號源吸收電流,才不會影響待放大信號以及對電路的放大結果產生影響。為什麼這麼說呢?
  • 實用技能 | ppt裡你踩過的那些坑
    看到這個標題,是不是想到上期的「word裡你踩過的那些坑」,今後歡迎留意實用技能組針對常用在線工具的「踩坑」系列。
  • Hello Blazor:(6)你必須踩過這5個坑,才算學會部署Blazor WebAssembly到靜態網站
    但是,你首先要踩過5個坑!1.部署可能有不熟悉部署流程的朋友,如果你了解,可以直接跳到第2部分。1.1創建Github Pages登錄Github後,創建一個倉庫,比如HelloBlazor。你以為結束了?不,下面才正式開始!2.踩坑2.1 所有資源文件404現象訪問網站,提示An unhandled error has occurred.
  • 程式設計師必備:Java日期處理的十個坑
    前言整理了Java日期處理的十個坑,希望對大家有幫助。
  • 賣家註冊美國公司時經常踩的坑,你佔了幾個?
    剛開始亞馬遜封店只是封一個站點,最近不少賣家爆出亞馬遜開始「連坐」了,如果你的美國站因違規操作被封店,同一帳號註冊的歐洲站、日本站也有可能被封。因為這次封店潮,很多賣家對「合規經營」開始有了「敬畏之情」,不過,也有賣家反映,自己明明是在遊戲規則之內做的,不知為何還是被亞馬遜給關店了。
  • 網紅自創美妝品牌的坑,你踩過幾個?
    據了解,張大奕在其新浪微博小號上傳了幾張圖片,稱自家洗面奶是打版CPB洗面奶,甚至比CPB有過之而無不及。在遭到網友的質疑後,她刪掉了發出來的微博,就再也沒回應過此事。除了洗面奶外,張大奕旗下多款美妝產品均遭質疑,如唇釉抄襲香奈兒、多功能彩妝棒子外型抄襲NARS腮紅棒,還有從外在到內裡都抄襲SUQQU的漸變腮紅的自家腮紅等等。
  • 獨立遊戲開發如何入門?當你踩完這些坑可能就懂行了
    做過UI,做過原畫,甚至為了縮減資金成本,也為了更能夠全面掌控獨立遊戲開發,前幾個月自學了程序。