Java: SoftReference логика работы?

Никогда не понимал, на какой хрен там три вида weak references

ЕМНИП для этого нужны не SoftReference, a WeakReference

Смысл в кеше если его сносит в чистую шальной GC, даж если памяти валом? Ой вей.

> Смысл в кеше если его сносит в чистую шальной GC, даж если памяти валом? Ой вей.

Вопрос "как тогда узнать удалил ли GC объект из SoftReference чтобы не менять время последнего доступа к SoftReference" означает, что ты допускаешь возможность, что GC удалит объект. Так что почему ты называешь GC шальным?

У тебя есть конкретные притензии к GC, когда он удаляет лишнего при "памяти валом"?

> Вопрос, как тогда узнать удалил ли GC объект из SoftReference чтобы не менять время последнего доступа к SoftReference?

Повторюсь, хотя и более подробно, что я для этой цели хранил бы у себя оба референса -- мягкий и слабый, и когда надо пройтись по кэшу, не меняя при этом время последнего доступа -- проходил бы через слабые референсы.

Возможно, что есть и другой способ -- но сильно сомневаюсь, т.к. ява -- это язык класса "жри что дают", а не "все можно сделать красиво".

И еще твой вопрос наводит на интересные мысли насчет структуры наследования. Потом напишу.

>Никогда не понимал, на какой хрен там три вида weak references

Бывшие C++'ники захотели рулить объектами.

weak references — дерьмо страшенное. Никогда ими не пользуйтесь, Ъ-явщики.

>Вопрос, как тогда узнать
этого знать не надо, если хочется знать можно использовать си и malloc

> weak references — дерьмо страшенное. Никогда ими не пользуйтесь, Ъ-явщики.

Поздравляю Шарик, ты... твои программы сложнее "hello world" будут течь.

Покуда тут толстый линуксоргуру порет чушь, поинтересуюсь у тебя, на чем основано твое мнение. Статьи и проч. будут кстати.

> Покуда тут толстый линуксоргуру порет чушь, поинтересуюсь у тебя, на чем основано твое мнение. Статьи и проч. будут кстати.

Сначала предложи иное, чем мое, решение твоей задачи, а потом уж рассуждай про толщину.

Запиши эти правила ведения дискуссии с тобой и повесь на стену. И прекращай троллить своими решениями задач от которых даже индусы плачут.

А нафиг тебе это надо? Почему в обертке вида WeakHashMap это дело не заюзать?

>Статьи и проч. будут кстати.

Джошуа Блох "Java. Эффективное программирование"

Потому что кеширование на WeakHashMap -- это Absurd.

Подсказка кроется в документации к WeakHashMap.

Спасибо щас погляжу.

Разьясни, из какого места, упомянутой тобой книги:
--
Another common source of memory leaks is caches. Once you put an
object reference into a cache, it’s easy to forget that it’s there and leave it in the
cache long after it becomes irrelevant. There are several solutions to this problem.
If you’re lucky enough to implement a cache for which an entry is relevant exactly
so long as there are references to its key outside of the cache, represent the cache
as a WeakHashMap; entries will be removed automatically after they become obso-
lete. Remember that WeakHashMap is useful only if the desired lifetime of cache
entries is determined by external references to the key, not the value.
More commonly, the useful lifetime of a cache entry is less well defined, with
entries becoming less valuable over time. Under these circumstances, the cache
should occasionally be cleansed of entries that have fallen into disuse. This can be
done by a background thread (perhaps a Timer or ScheduledThreadPoolExecu-
tor) or as a side effect of adding new entries to the cache. The LinkedHashMap
class facilitates the latter approach with its removeEldestEntry method. For
more sophisticated caches, you may need to use java.lang.ref directly.
----

можно вынести следующую идею "weak references — дерьмо страшенное. Никогда ими не пользуйтесь, Ъ-явщики." ? Тут как ни странно наоборот предписано юзать. Кроме того сабж не описан вообще (не забыл что в сабже)?

>Потому что кеширование на WeakHashMap -- это Absurd.

Можешь пояснее выражаться? Смотрел жабодок к JDK 1.6, ничего криминального не нашел. Если на ключ в WeakHashMap никто не ссылается он удаляется из памяти при следующем проходе GC.

А теперь скажи, когда случится этот обход?

>А теперь скажи, когда случится этот обход?

Может и никогда. Но если ключ лежит в пуле свежесозданных объектов, то долго в памяти он не задержится.

Ага, хорошо, идем дальше. А какова задача кеша? Т.е. кешируем мы данные (в данном случае результаты запроса к серверу) чтобы воспользоваться ими потом, или ради того чтобы GC их снес как только мы зазеваемся?

Белка, заюзай сторонний кеш вместо изобретения велосипеда. Будет и глобально и надежно разом.

Меня повесят за апплет который загружается с сервера полчаса и зажирает всю память.

По умолчанию раз в минуту, но переопределяется. http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html ближе к концу.

Да, и

Starting with 1.3.1, softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap. This value can be adjusted using the -XX:SoftRefLRUPolicyMSPerMB flag, which accepts integer values representing milliseconds.

http://java.sun.com/docs/hotspot/HotSpotFAQ.html#gc_softrefs

Спасибо, но я это знаю, это одна из подсказок советчикам WeakReference.

Ну и на всякий случай

This means that the general tendency is for the Server VM to grow the heap rather than flush soft references, and -Xmx therefore has a significant effect on when soft references are garbage collected.

On the other hand, the Client VM will have a greater tendency to flush soft references rather than grow the heap.

Это уже полезная инфа, и означает она, что толку от softreference нет, а жаль.

С софт референсами я сталкивался как раз в серверной VM. Индоиранский код - они постоянно проверялись на живость, в результате не чистились вообще никогда. Там EhCache спас.

Что-то я не понимаю, оно таки будет их оставлять жить максимум секунду или покуда есть память?

>Т.е. кешируем мы данные (в данном случае результаты запроса к серверу) чтобы воспользоваться ими потом, или ради того чтобы GC их снес как только мы зазеваемся?

Если в кеше ключа нет выфетчиваем с сервера и заносим в кеш, иначе берем из кеша. Должно работать нормально.

Мдя, бесполезно.

в апплете пожалуй что нет. Там вообще с памятью, насколько я помню, не то, чтобы очень.

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

В клиентской VM если будет заканчиваться память, он предпочтет убить софтреференсы (выделение нового чанка дороже). Гарантирована жизнь в течение секунды _на свободный мегабайт_. В ситуации близкой к oom убъет безо всякой секунды. Еще интереснее в самом конце:

Prior to version 1.3.1, the Java HotSpot VMs cleared soft references whenever it found them.

Может будет полезно: http://izen.dev.juga.ru/notebook/solutions/imagescache.html

Предложения, замечания принимаются.

В общем, если не надо, чтобы они жили, то и проверять не надо :) Дело в том, что до tenured и old gc далеко не всегда доходит, да и дольше такие проходы.

Айбиэмовские статьи рассказывали, что мол прибъет только перед тем как кинуть OutOfMemoryException, и если это не спасет то таки кинет, но видимо ситуация несколько иная 8(

>Мдя, бесполезно.

Надо решать проблемы по мере поступления. Если политика вытеснения в WeakHashMap'е тебя не будет устраивать можешь написать аналог в любой момент. Когда мне надо было удалять точно по таймауту листенеры входящих запросов которыми так никто и не востользовался лично я сделал при помощи обычного HashMap'а и треда.

Думаю, что если сделать реализацию Map.Entity наследованным от SoftReference (как сделано в WeakHashMap емнип), то дествительно можно обойтись без проверки, в общем поработать над алгоритмом.

Почему иная? Убъет референсы, если это не поможет, попытается выделить новый кусок памяти, если и его нет, то OutOfMemoryException. А в серверной vm сначала попытается выделить память, потом пойдет убивать софтреференсы. Но это поведение HotSpot. Другие VM могут иначе делать - стандарта на это нет.

обычный синглетон с хешмапом и стандартным фокусом - объект из кеша не удалили вручную - память занята (что и побудило меня залезть в дебри java.util.ref). ???

Не надо создавать себе проблемы использованием неподходящих сущностей когда есть лучшие аналоги.

Вспомнил. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/ReferenceQueue.html#poll() - вот этим проверять можно, если не ошибаюсь.

И статья про WeakHashMap и кэш http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understandin...

> И прекращай троллить своими решениями задач от которых даже индусы плачут.

Ява специально создавалась для индусов. И цель, чтобы они не плакали -- не ставилась :-)

А пока что ты даже вместе с абсурдом и свр69 решения лучше не нашел. Так что ждем-с...

З.Ы. мое понимание задачи: имеется кэш. По нему иногда надо делать проходы с целью найти и уничтожить хлам. Эти проходы желательно не делать через SoftReference, чтобы не апдейтить время последнего доступа через него.

>А пока что ты даже вместе с абсурдом и свр69 решения лучше не нашел. Так что ждем-с...

Я предложил сделать тред который удаляет ключи после того как их не трогали определенное время и не ипать моск.

> Я предложил сделать тред который удаляет ключи после того как их не трогали определенное время

А как ты определишь это самое время? (SoftReference отдает тебе его?)

>> Я предложил сделать тред который удаляет ключи после того как их не трогали определенное время

>А как ты определишь это самое время? (SoftReference отдает тебе его?)

Перегрузить в мапе метод get чтобы он обновлял таймштамп каждый раз когда был вызван.