2013-08-29 2 views
2

В этой связи hereЛи ThreadLocal переменного должен быть статическими, чтобы представлять утечку памяти

Они описывают утечки памяти при использовании загрузчика классов. Теперь этот комментарий:

Классный загрузчик будет удален сборщиком мусора, только если на него не ссылаются. Все классы содержат ссылку на свой загрузчик классов, и все объекты содержат ссылки на их классы. В результате, если приложение выгружается, но один из его объектов все еще удерживается (например, кешем или локальной переменной), базовый загрузчик классов не может быть удален сборщиком мусора!

Я понимаю несколько. Но в той части, когда они говорят:

(например, кэш или ThreadLocal переменной)

Я правильно сказать, что кэшем они означают статические ссылки и ThreadLocal, они означают нестационарную переменную потока. Я говорю об этом, потому что все объяснения кода утечек потоковой памяти делают переменную threadlocal статичной. Например, этот вопрос in SO

Другой вопрос с комментарием о кеше: статическая переменная будет GC-ed, когда приложение будет работать, так почему это проблема?

+0

Не возражаете ли вы пометить это как Java или ваш вопрос будет сохранен для других GC, например .Net? – rene

ответ

1

Каждый поток имеет (эффективно) WeakHashMap, где Data является некоторым объектом, объект относится к классу, класс относится к ClassLoader, ClassLoader относится ко всем классам, которые он загрузил (например, ThreadLocalHolder), классу ThreadLocalHolder имеет статическую, которая содержит ThreadLocal, и поэтому значение WeakHashMap относится к ключу, что предотвращает сбор ключа + до тех пор, пока весь объект Thread не исчезнет. См. Мой this answer для более подробного объяснения и примера.

Смежные вопросы