轉載自??性能優化之拋棄Calendar

目前在做限流相關的需求，有這么一個限流策略，和用戶相關，當系統發生故障時，允許一個非核心接口按照用戶的百分比進行限流，如果完全按照UUID進行hash，那么每次都是限制同一批的用戶，如果在UUID的基礎上加上當天的日期，那么就可以有效的避免這個問題。

所以在這個需求中，每次請求都需要拿到當前的日期，不過精確到天即可。 嗖~的一下，完成了如下代碼

Calendar calendar = Calendar.getInstance(); String time = "" + calendar.get(Calendar.YEAR) + calendar.get(Calendar.MONTH) + calendar.get(Calendar.DAY_OF_MONTH);

很簡單是不是，不過寫完之后，很快就被業務同學diss了，Calendar性能太差了，在QPS很高的情況下，會使接口的999線劣化。

?

QPS高的業務真是惹不起... （丟）

為什么Calendar不行，因為每次請求都要創建一個Calendar實例，這個創建過程比較的耗時（qps低的時候可以忽略這種消耗），但是做基礎組件的，應該考慮各種場景。

因為只需要獲取到與天相關數據，所以想到了另一個簡單的解決方案

private static final int DAY_MILLIS = 24 * 60 * 60 * 1000; long day = System.currentTimeMillis() / DAY_MILLIS;

通過當前的時間戳（毫秒級別），除以一天的毫秒數，得到的結果就是從1970 到今天經歷過的天數，這完全符合當前的需求。

這個解決方案，只是恰好可以滿足這種需求，對于其它更復雜一點的需求，我這里推薦使用 JodaTime組件。

下面通過Openjdk的JMH類庫，對上述三種情況進行性能基準測試，還沒有接觸過JMH的同學，可以在官網上進行學習，傳送門

@OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(Mode.AverageTime) public class Main {static int millis = 24 * 3600 * 1000;public static void main(String[] args) throws Exception {Options options = new OptionsBuilder().include(Main.class.getName()).forks(1).build();new Runner(options).run();}@Benchmark@Threads(5)public void runCalendar() {Calendar calendar = Calendar.getInstance();}@Benchmark@Threads(5)public void runJoda() {DateTime dateTime = new DateTime();}//@Benchmark@Threads(5)public void runSystem() {long result = System.currentTimeMillis() / millis;}}

使用benchmark之前，需要引入相關依賴

<dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-core</artifactId><version>1.21</version> </dependency> <dependency><groupId>org.openjdk.jmh</groupId><artifactId>jmh-generator-annprocess</artifactId><version>1.21</version><scope>provided</scope> </dependency>

?

?

最終結果如下

這里只是測試了Calendar和Joda對象的創建耗時，可以發現Joda的性能比Calendar整整高了10倍，真的不可忽略。

?

總結

以上是生活随笔為你收集整理的性能优化之抛弃Calendar的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。