Утечка ресурсов ThreadLocal и WeakReference
Вот как я это сделал
Мой элемент HTML
Мой элемент сценария
// use Jquery to get data from proxy Html element
var playlist_data = $('#my_playlist_data').data("playlist");
См. . data () документирование для более
6 ответов
ThreadLocal uses a WeakReference internally. If the ThreadLocal is not strongly referenced, it will be garbage-collected, even though various threads have values stored via that ThreadLocal.
Additionally, ThreadLocal values are actually stored in the Thread; if a thread dies, all of the values associated with that thread through a ThreadLocal are collected.
If you have a ThreadLocal as a final class member, that's a strong reference, and it cannot be collected until the class is unloaded. But this is how any class member works, and isn't considered a memory leak.
Update: The cited problem only comes into play when the value stored in a ThreadLocal strongly references that ThreadLocal—sort of a circular reference.
In this case, the value (a SimpleDateFormat), has no backwards reference to the ThreadLocal. There's no memory leak in this code.
Я предполагаю, что вы прыгаете через эти обручи, поскольку SimpleDateFormat не является потокобезопасным .
Хотя мне известно, что я не решаю вашу проблему выше, могу я предложить вам взглянуть на Джода для вашей работы с датой / временем? В Joda есть потокобезопасный механизм форматирования даты и времени. Вы также не будете тратить свое время на изучение Joda API, поскольку это основа для предложения нового стандартного API даты / времени.
Там не должно быть такой проблемы.
Ссылка ThreadLocal на поток определяется, чтобы существовать только до тех пор, пока соответствующий поток жив (см. Javadoc) - или другими словами, как только поток не работает, если ThreadLocal была единственной ссылкой на этот объект, тогда объект получает право на сборку мусора.
Так что либо вы обнаружили настоящую ошибку, и должны сообщить это, или вы делаете что-то еще не так!
Я понимаю, что это не совсем ответ на ваш вопрос, но, как правило, я не предлагаю использовать ThreadLocal в ситуации, когда нет четкого снесите в конце запроса / взаимодействия. Классика делает такие вещи в контейнере сервлетов, на первый взгляд это кажется нормальным, но поскольку потоки объединены в пул, возникает проблема с ThreadLocal , висящим на ресурсе даже после того, как каждый запрос был обработан. .
Предложения:
- Используйте фильтр подобной оболочки для каждого взаимодействия, чтобы очистить ThreadLocal в конце каждого взаимодействия
- Вы можете использовать альтернативу SimpleDateFormat, например FastDateFormat из commons-lang или Joda, как кто-то уже предложил
- Просто создавайте новый SimpleDateFormat каждый раз, когда он вам нужен. Кажется расточительным, я знаю, но в большинстве приложений вы просто не заметите разницы
В вашем примере вообще не должно быть проблем с использованием ThreadLocal.
Локальные переменные потока (и синглтоны тоже!) Становятся проблемой, когда локальные переменные потока устанавливаются на экземпляры, загруженные загрузчиком классов для будет выгружен позже. Типичная ситуация в контейнере сервлета (например, tomcat):
- Веб-приложение устанавливает локальный поток во время обработки запроса.
- Поток управляется контейнером.
- Веб-приложение не должно быть развернуто.
- Загрузчик классов веб-приложения не может быть испорчено, потому что остается ссылка: от потока, локального к экземпляру, к его классу, к его загрузчику классов.
То же самое с одиночными экземплярами (java.sql.DriverManger и драйверы JDBC, предлагаемые веб-приложением).
Так что избегайте таких вещей, особенно в средах, которые не находятся под вашим полным контролем!
Просто чтобы добавить к тому, что сказал @Neil Coffey, это не должно быть проблемой, пока ваш экземпляр ThreadLocal статичен. Поскольку вы продолжаете вызывать get () в статическом экземпляре, он всегда должен содержать одну и ту же ссылку на ваше простое средство форматирования даты. Следовательно, как сказал Нил, когда поток завершается, единственный экземпляр простого средства форматирования даты должен иметь право на сборку мусора.
Если у вас есть числа или какая-либо другая форма отладки, которая показывает появление проблем с ресурсами, то это уже другая история. . Но я считаю, что в таком виде проблем быть не должно.