從文件中最有效地寫入和讀取LocalDateTime

Question

將LocalDateTime實例寫入文件然後從文件讀取並將其轉換回LocalDateTime對象的最快方法是什麼？

我用來保存毫秒，然後將其轉換爲Date對象。它看起來相當快，但現在我正在處理Java 8的LocalDateTime，並不清楚什麼是最有效的方式來保存和從文件中檢索它。

我不認爲使用DateTimeFormater是一個好主意，因爲它需要更多資源將其轉換爲String，然後解析String。

時區不相關。

Answer 1

如果要保存毫秒並且時區不重要，則可以使用java.time.Instant類 - 只有LocalDateTime無法獲得毫秒，因爲此類沒有時區/偏移量信息。

// get the current date 
Instant instant = Instant.now(); 

// get milliseconds (equivalent to java.util.Date.getTime()) 
long millis = instant.toEpochMilli(); 

// get Instant from milliseconds 
Instant instant = Instant.ofEpochMilli(millis); 

---

如果你有LocalDateTime，不過，你可以很容易地將其轉換爲Instant：

LocalDateTime d = LocalDateTime.now(); 
Instant instant = d.atOffset(ZoneOffset.UTC).toInstant(); 

此代碼顯然假定在LocalDateTime值對應於一個UTC日期和時間。要轉換Instant回LocalDateTime：

LocalDateTime d = LocalDateTime.ofInstant(instant, ZoneOffset.UTC); 

---

PS：你測量系統性能知道「快」是一個真正的問題？無論如何，我以「標準」方式（基於API提供的最直接的方式）來做事情，那就是你想要的？

也許你可以認爲創建一個Instant作爲一個「中介」對象使得事情不那麼「快」（但是你仍然需要測量它）。如果是這樣的話，你可以從LocalDateTime直接米利斯（假設它對應於UTC日期和時間）：

// get the current date 
LocalDateTime d = LocalDateTime.now(); 
// get milliseconds value 
long millis = d.toEpochSecond(ZoneOffset.UTC) * 1000 + d.get(ChronoField.MILLI_OF_SECOND); 

// get LocalDateTime from millis 
LocalDateTime d = LocalDateTime.ofEpochSecond(millis/1000, (int) (millis % 1000) * 1000000, ZoneOffset.UTC); 

需要注意的是java.time類具有毫微秒的精度，所以得到毫秒很重要讓你失去這個精度。

如果你不想失去毫微秒的精度，並不一定需要與millis的值，則可以存儲2個不同的數字（時代天和納米天的）：

// get the current date 
LocalDateTime d = LocalDateTime.now(); 

// get values from LocalDateTime 
long epochDay = d.toLocalDate().toEpochDay(); 
long nanoOfDay = d.toLocalTime().toNanoOfDay(); 
// save both values to file 

// retrieve the LocalDateTime from the values 
LocalDateTime d = LocalDateTime.of(LocalDate.ofEpochDay(epochDay), LocalTime.ofNanoOfDay(nanoOfDay)); 

這不需要轉換爲UTC，但它需要2個數字而不是1個。您可能會認爲創建LocalDate和LocalTime會使事情變得更慢，但這兩個對象始終由LocalDateTime（在所有情況下）內部創建的始終爲。

不確定，但是，如果所有數學運算都比使用Instant「更快」。這是一個測試問題，看看哪一個最適合你的情況。

但對我來說，在清晰度和代碼易於維護的是使用Instant（或使用時代天和納米天的最後方法）方面最「有效」的。除非您處理數百萬條記錄，否則我不確定這是否會成爲性能問題。

---

我做了一個簡單的測試（運行超過10萬次每種情況下），而最後一種方法（使用劃時代一天納米天的）似乎是最快的。但差距不到1秒。只有運行2個億次次，我纔有20秒的差距，所以如果你處理了這麼多的記錄，也許這是值得的。

關於其他資源（內存使用情況，CPU，I/O），我沒有檢查。但無論如何，性能問題對於每個環境都是非常具體的：取決於系統的設計方式，系統的部件/模塊/組件之間的相互影響以及其他因素，每種情況下都可能會有不同的瓶頸。最後，你必須測試每種方法，看看哪一種方法在你的系統中表現最好。或者你可以得出這樣的結論：它不會產生顯着的差異（對於少於幾百萬條記錄的情況，也許它不會 - 但是你只有在基準化之後才知道）。