java - 枚举中的 ThreadLocal SimpleDateFormat？

Question

我正在对我们的日期格式化代码进行一些重构，因为由于各种原因我们设法引入了许多不一致的地方。我知道最好有一个 ThreadLocal SimpleDateFormat。在这里讨论之后，我们不确定在 Enum 中使用时是否需要 ThreadLocal，因为我们从不更改实例并且不公开它，所以它不能被改变？如果它是仍然需要作为一个枚举，像这样，会破坏任何东西吗？有没有其他东西坏了或者没有按照我认为应该做的做？基本上，我不必使用 ThreadLocal 做太多工作，我不确定其含义，尤其是它如何与 Enum 交互。

public enum DateFormat {
DATE(newThreadLocalSimpleDateFormat( "MM/dd/yyyy" )),
LONG_DATE(newThreadLocalSimpleDateFormat("MMMM dd, yyyy")),
TIMESTAMP(newThreadLocalSimpleDateFormat( "MM/dd/yyyy hh:mm:ss aa" ));

private transient final ThreadLocal<SimpleDateFormat> formatter;

DateFormat( final ThreadLocal<SimpleDateFormat> formatter ) {
    this.formatter = formatter;
}


public  String format ( final Date date ) {
    return this.formatter.get().format( date );
}

private static ThreadLocal<SimpleDateFormat> newThreadLocalSimpleDateFormat( final String frmtString ) {
    return new ThreadLocal<SimpleDateFormat>() {
        @Override
        protected SimpleDateFormat initialValue() {
            return new SimpleDateFormat( frmtString );
        }
    };
}

}

Answer 1

这里的枚举是一个全局常量，用作从线程局部变量中检索正确格式化程序的便捷方式。枚举是不可变的，但如果它引用具有可变状态的事物，这些事物仍然可能存在问题。

当你说

we never change the instance and don't expose it so it can't be mutated

您误解了线程安全问题的本质。问题在于 SimpleDateFormat 的内部状态不受多线程访问保护，因此当多个线程访问同一个格式化程序实例时，这些线程中的任何一个都可以更改其他并发线程操纵的状态，从而破坏结果。

处理这个格式化程序的选择是:

• 保持 ThreadLocal 不变，以便每个线程都有自己的格式化程序副本；在某些情况下，最大的危险是线程局部对象可能无法正确清理，因此从池中选择的线程(您正在使用线程池，对吗？)可能具有与先前使用相关联的变量，但在这种情况下它可能更像是一个功能:如果所有线程无论如何都需要它，则最好保留格式化程序，

• 为每次调用创建一个新的格式化程序，这样就不会共享任何内容(快速、简单且线程安全，但这会在格式化程序被丢弃时产生垃圾；让垃圾收集器更努力地工作会降低性能)，

• 同步对格式化程序的访问，以便线程不能并发访问它(可能是最没有吸引力的选择，它可能会导致瓶颈)

• 使用 DateFormat 的不同实现，如 FastDateFormat，它是线程安全的(线程安全可能意味着该实现是锁定或复制状态，因此可能存在缺点，需要进行一些测试才能看到结果).

保留现有的 ThreadLocal 或检查线程安全格式化程序的替代方案可能是这里的最佳选择。保留您所拥有的似乎是一个安全的选择。

如果没有线程池，Threadlocal 会变得不那么吸引人，因为线程的生命周期更短，因此对给定格式化程序的重用更少。线程池是一个好主意，原因有很多(主要是确保错误条件不会导致您的应用程序用完线程，以便您的应用程序可以以可控的方式降级)，如果您不使用它们，您应该.

对我而言，这段代码最奇怪的地方是枚举必须是可序列化的，但 threadLocal 是不可序列化的，因此必须将其声明为 transient 的。如果这个东西确实被序列化并因某种原因反序列化，反序列化的副本将有一个空的 threadLocal。实际上，无论如何这都不是您想要序列化的东西(您不会将其存储在 HttpSession 中或将其传递给另一个 JVM)，因此这似乎是一个小到不存在的风险。