Java 7 Calendar.getInstance，TimeZone.getTimeZone 同步且缓慢，有什么解决方法吗？答案

【问题标题】：Java 7 Calendar.getInstance, TimeZone.getTimeZone got synchronized and slow, any work arounds?Java 7 Calendar.getInstance，TimeZone.getTimeZone 同步且缓慢，有什么解决方法吗？
【发布时间】：2012-10-20 01:01:25
【问题描述】：

将我的运行时升级到 Java 7 后，我看到了难以置信的缓慢......而且我的程序将所有时间都花在了 SimpleDateFormat 构造函数中。正如这里的一篇精彩文章所述：http://coffeedriven.org/?p=83TimeZone 代码现在正在检查static synchronized 方法getDefaultInAppContext() 中是否存在应用程序上下文。

对我来说，问题是 Spring Batch 文件阅读器代码为它读取的每一行创建一个 new SimpleDateFormat 对象！

有人可以解决这个问题吗？

【问题讨论】：

标签： java performance synchronized simpledateformat

【解决方案1】：

SimpleDateFormat一直很慢，现在我知道Java 7更慢了。

像@MK 一样，我们也缓存它们。但请注意，它不是线程安全的。我们最终创建了ThreadLocals。

强烈推荐JodaTime，虽然我没用过，也不知道它有日期格式

【讨论】：

问题是我正在使用 Spring Batch 并且日期格式调用在那里，所以我不能自己更改为 JodaTime。
您可以使用AspectJ 部署生产方面以使用JodaTime 而不是SimpleDateFormat 或仅使用缓存的SimpleDateFormat 对象

【解决方案2】：

我们通过更改 Spring Batch 本身解决了这个问题。目前，更改位于本地副本中，但我已输入 Jira 问题并希望将我们的修复贡献回 Spring Batch 本身。

更改本身是将 SimpleDateFormat 的使用从成员变量更改为注入变量（无论如何这似乎更像 Spring）。这让我们可以控制它的生命周期。

【讨论】：

【解决方案3】：

我很高兴地报告此问题已在 Java 9 中的 JDK-8074002 中得到修复。现在已降至 #clone()。

【讨论】：

【解决方案4】：

Joda Time 是用于日期时间计算的最佳日期时间 API。请记住，如果您的要求需要不同的时区，您应该使用 JodaTime API。

【讨论】：

“必须”这个词在这里太强了。我当然同意 Joda Time 是一个更好的 API，但并不是标准库不支持不同的时区。
@JonSkeet;我不是说标准。库没有能力，但在这里我的意思是在 JOda Time API 中有很多内置的扩展功能，以方便和节省时间。对不起我的工作“必须”。 :)