1. 程式人生 > >java8的時間和`Date`的對比

java8的時間和`Date`的對比

rgs 捕獲異常 get 沒有 zone lis 成本 ride amp

java8提供了新的時間接口。相對Date,Calendar,個人感覺最大的好處是對時間操作的學習成本很低,比Calendar低。

1.LocalDate,LocalTime,LocalDateTime
LocalDate 代表日期,LocalTime表示時刻,類似11:23這樣的時刻。 LocalDateTime就是前面2個的結合,這個可以從java.time.LocalDateTime#toString的代碼看出一二:


@Override
public String toString() {
    return date.toString() + ‘T‘ + time.toString();
}
date,time 在java.time.LocalDateTime中

/**
 * The date part.
 */
private final LocalDate date;
/**
 * The time part.
 */

private final LocalTime time;
實際使用中,計算日期就用LocalDate,計算日期加時刻用LocalDateTime,如果只有時刻就是LocalTime(感覺在說廢話)
這三個的用法基本上一樣,通過方法名就知道用法那種

1.1 獲取當前時間的對象

LocalDateTime localDateTime = LocalDateTime.now();
Date date = new Date();

localDateTime相比Date更像是一個工具類,就是為了時間操作使用。其構造方法是私有的。

1.2 從字符串中解析
字符串 2019-01-11 解析成時間對象

String str = "2019-01-11";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
LocalDate localDate = LocalDate.parse(str, formatter);

SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd");
try {
    Date date = simpleDateFormat.parse(str);
} catch (ParseException e) {
    e.printStackTrace();
}

DateTimeFormatter的包路徑是java.time.format和LocalDate一樣在java.time下面,而SimpleDateFormat和Date是不同的。所以當判斷引入路徑的時候更容易判斷。
當解析失敗的時候,兩個異常的拋出不一樣,DateTimeFormatter拋出的是DateTimeParseException,繼承自RuntimeException,而ParseException明顯繼承的是Exception。
個人感覺這個思路是,前者如果拋出異常那就是編程上錯誤,而後者則是的程序代碼的不穩定性。我更傾向於第一種的異常設計,應該加強對入參的檢測判斷,而不是通過捕獲異常去處理入參的錯誤。(類似NumberFormatException)

1.3 LocalDate比Date更強的初始化時間
Date 設置某個日期,基本上3個方式,時間戳/Calendar/字符串解析。相對的LocalDate就簡單了很多

LocalDate.of(2019,1,12);
其他的也一樣
技術分享圖片

1.4 時間戳的轉換

在這裏時間戳的轉換不如Date直接。主要因為LocalDate本身是沒有時區的。

時間戳傳LocalDateTime

long timestamp = System.currentTimeMillis();
Instant instant = Instant.ofEpochMilli(timestamp);
LocalDateTime.ofInstant(instant, ZoneId.systemDefault());

LocalDateTime轉時間戳

LocalDateTime dateTime = LocalDateTime.now();
dateTime.toInstant(ZoneOffset.ofHours(8)).toEpochMilli();
dateTime.toInstant(ZoneOffset.of("+08:00")).toEpochMilli();
dateTime.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();

關於時區的計算也很簡單,就是相差幾個小時就加上多少秒
技術分享圖片

有些時區計算的時候,不妨自己加時間也一樣,elasticsearch+logstash設置@timestamp時間是默認UTC Z的時間,和咱們差了8個小時

LocalDateTime.parse(json.getString("@timestamp"), DateTimeFormatter.ISO_DATE_TIME).plusHours(8L)
1.5 和Date互轉

import java.time.Instant;
import java.util.Date;

public class Main {
  public static void main(String[] args) {
    Date  dt =  new Date(); 
    System.out.println("Date: "  + dt);

    Instant in = dt.toInstant(); 
    System.out.println("Instant: "  + in);

    Date  dt2  = Date.from(in); 
    System.out.println("Date: "  + dt2);
  }
}

Instant 和 LocalDate或LocalDateTime 就不贅述了...

1.6 更好的理解和操作方式
Date、Calendar的操作,例如設置月份,day of week 都有些讓人迷惑,例如1月的定義是0,周一是0。1號好像也是0吧(我真沒咋用過這東西,現用現百度...

LocalDate感覺好多了。例如DayOfWeek是枚舉類型。使用枚舉就不會理解錯了吧 技術分享圖片

很多日期和時間操作,無非就是加減時間和比較.
使用‘加’的示例:
技術分享圖片

不用再去使用一個不熟悉的Calendar去操作了(Calendar提供的接口都是啥玩意,get,set的)

Calendar cal = Calendar.getInstance();
cal.set(Calendar.MONTH, cal.get(Calendar.MONTH) + 1)
  1. 線程安全性比較
    LocalDate...系列是線程安全的
    額..每一個字段都用了final關鍵字了,都變不了... 所以進行操作後都是返回新的copy對象 技術分享圖片

至於說Date線程不安全,get,set的肯定在多線程的時候容易出現問題,不過set方法已經都@Deprecated廢棄了。當然不是因為線程安全問題廢棄的,是因為有了更好的替代

Calendar.set(Calendar.DAY_OF_MONTH, int date)
不過感覺還是不如這個更清晰明了

LocalDate.of(2019,1,12);
2.1 SimpleDateFormat的線程安全性
參考:深入理解Java:SimpleDateFormat安全的時間格式化

在一定負載情況下,SimpleDateFormat會出問題的。簡單測試一下


package open.note;

import java.text.SimpleDateFormat;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Date;
import java.util.concurrent.CountDownLatch;
import java.util.function.Consumer;

public class UnSafeTest {

    private static String time = "2019-01-11 11:11:11";
    private static long timestamp = 1547176271000L;
    private static LocalDateTime dateTime = LocalDateTime.of(2019,1,11,11,11,11);
    private static SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    private static DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");

    public static void main(String[] args) {
        dateFormatTest((obj)->{
            try {
                Date date = dateFormat.parse(time);
                if (date.getTime() != timestamp){
                    System.out.println(date);
                }
            } catch (Exception e) {
                System.out.println(e.getMessage());
            }
        });
        System.out.println("---------------");
        dateFormatTest((obj)->{
            try {
                LocalDateTime dateTime = LocalDateTime.parse(time,formatter);
                if (!dateTime.isEqual(UnSafeTest.dateTime)){
                    System.out.println(dateTime);
                }
            } catch (Exception e) {
                System.out.println(e.getMessage());
            }
        });
    }
    private static void dateFormatTest(Consumer runnable){
        CountDownLatch countDownLatch = new CountDownLatch(1000);
        for (int i = 0; i < 1000; i++) {
            new Thread(()->{
                runnable.accept(null);
                countDownLatch.countDown();
            }).start();
        }
        try {
            countDownLatch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

輸出結果

multiple points
multiple points
empty String
Sat Jan 11 11:11:11 CST 111
Fri Jan 04 11:11:11 CST 2019
For input string: ""
Mon Dec 31 11:11:11 CST 2018
Mon Dec 31 11:11:11 CST 2018
For input string: ""
Tue Jan 11 11:11:11 CST 42101

測試過程中,SimpleDateFormat 1000個線程裏,有5次,時間解析錯了,5次異常了(時間錯了,比拋出異常還可怕)
DateTimeFormatter只是對比參考一下,未出現異常(人家已經聲明是線程安全了...)
當然SimpleDateFormat線程不安全應該人盡皆知的,但依然有不安全的使用,但每次使用都new一個實例,當負載大的時候也不好。所以一個線程一個SimpleDateFormat實例應該可以的。

最後
java8 對時間操作的類還有很多 到java.time包下去看看,以後總會用得到的地方。

Instant:時間戳
Duration:持續時間,時間差
LocalDate:只包含日期,比如:2016-10-20
LocalTime:只包含時間,比如:23:12:10
LocalDateTime:包含日期和時間,比如:2016-10-20 23:14:21
Period:時間段
ZoneOffset:時區偏移量,比如:+8:00
ZonedDateTime:帶時區的時間

Clock:時鐘,比如獲取目前美國紐約的時間

java8的時間和`Date`的對比