Неправильная практика сохранения локальных значений потоков в статическом конечном поле?

Question

я наткнулся на следующий код в прежней системе,

private static final ThreadLocal<DateFormat> dateFormatThreadLocal = new ThreadLocal(){ 

    @Override 
    protected Object initialValue() { 
     //Set initial value 
     return new SimpleDateFormat(""); 
    } 
}; 


private static final DateFormat someValue = dateFormatThreadLocal.get(); 

Однако я следующие вопросы.

1.) Рекомендуется ли определять локаторы потоков как окончательные. (Я знаю, что статический - это хорошо)

2.) Неплохо ли держать вызов thread local.get() в статической (или как статической, и конечной) переменной экземпляра? (если мы это делаем, это не препятствует цельной цели локализации на первом месте)

Answer 1

1.) Неплохо ли определять локаторы потоков как окончательные. (Я знаю, что статические отлично)

Если вы не приписывая dateFormatThreadLocal то final не имеет никакого значения. Однако, это вообще хорошая идея, потому что это предотвращает вас от случайно, назначая ему.

2.) Неплохо ли удерживать вызов local.get() в статической (или как статической, и конечной) переменной экземпляра? (если мы это сделаем, это не мешает всей цели иметь местно-локальное на первом месте)

Нет, это не так. Собственно, если вы do сделайте это, то это победит всю цель иметь нить-локальную в первую очередь.

Какую бы ни быструю загрузку класса сначала загрузил свой SimpleDateFormat и сохранил ссылку на этот объект в someValue. И тогда всякий раз, когда вы используете someValue, текущий поток будет использовать , чтобы этот файл SimpleDateFormat (который он получил раньше) вместо вызова dateFormatThreadLocal.get() и получения его собственного.

Если вы используете ThreadLocal, то предположительно вы не хотите, чтобы каждый поток использовал один и тот же объект - в противном случае зачем его использовать?