我是否需要在以下情况下调用ThreadLocal.remove

而不是编写以下非线程安全方法。我是否需要在以下情况下调用ThreadLocal.remove

private static final Calendar calendar = Calendar.getInstance(); 
public void fun() { 
    // Going to call mutable methods in calendar. 
}

我将其更改为一个线程安全的版本。

public void fun() { 
    final Calendar calendar = Calendar.getInstance(); 
    // Going to call mutable methods in calendar. 
}

而不是为同一线程创建一个新的实例，甚至每一次，我通过

public void fun() { 
    final Calendar calendar = getCalendar(); 
    // Going to call mutable methods in calendar. 
} 

/** 
* Returns thread safe calendar. 
* @return thread safe calendar 
*/ 
public Calendar getCalendar() { 
    return calendar.get(); 
} 

private static final ThreadLocal <Calendar> calendar = new ThreadLocal <Calendar>() { 
    @Override protected Calendar initialValue() { 
     return Calendar.getInstance(); 
    } 
};

对于我的第三个方法做了改进，是否有任何需要调用ThreadLocal.remove？

来源

2010-08-22 Cheok Yan Cheng

如果你的唯一意图是使它线程安全，那么确实没有必要这样做。但是，当线程由一个线程池维护时，并且您的意图更多地是从线程池中为每个新释放的线程赋予其自己的初始值，那么您应该这样做。

来源

2010-08-22 06:12:45 BalusC

正如@BalusC所说，这取决于你所关心的。

我怀疑您使用本地线程回收Calendar对象实际上可能比您通过不致电Calendar.getInstance()节省的成本更高。这具有过早微观优化的气味。

来源

2010-08-22 07:24:26

但是，Joshua Bloch甚至建议使用ThreadLocal来处理SimpleDateFormat示例。（我打算用于日历，SimpleDateFormat和NumberFormat） - http://old.nabble.com/Threadlocals-and-memory-leaks-in-J2EE-td13097957.html#a13097957 – 2010-08-22 08:03:53

但没事！优化规则＃1 - 首先分析您的应用程序。 – 2010-08-22 08:14:58

@Yan Cheng'Calendar'应该是一个相当便宜的构造对象。 – 2010-08-22 10:34:13

我是否需要在以下情况下调用ThreadLocal.remove

回答

相关问题