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

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

А как насчет put *того же* самого объекта по *тому же* самому ключу? Обновит тайштамп? А это правильно?

А если у тебя 2 таких коллекции? Они правильно посчитают свободне место в памяти?

Короче, костыль.

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

> время

Т.е. разумное поведение GC по убиванию софт-референсов при недостатке памяти, а не чисто по времени, ты повторять не собрался? Или ты реализуешь некий listener, который GC будет дергать, когда памяти стало мало?

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

>А как насчет put *того же* самого объекта по *тому же* самому ключу? Обновит тайштамп? А это правильно?

Этой проблемы не существует

>А если у тебя 2 таких коллекции? Они правильно посчитают свободне место в памяти?

Количество памяти тут совершенно параллельно.

>Короче, костыль.

Этот способ гарантирует именно то поведение которое от него ожидается - убиение висячих ссылок по таймауту. Чего еще надо?

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

>Т.е. разумное поведение GC по убиванию софт-референсов при недостатке памяти, а не чисто по времени, ты повторять не собрался?

Количество памяти меня не колышет. Цель - исключить висячие ссылки. Она достигнута.

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

Таймштамп в качестве (обновляемого по запросу) ключа? Оригинально. Плюс отдельный фоновый тред, проходящий по кэшу для убиения устаревших ключей (и обнулению ссылок на объекты в мапе!).

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

>Таймштамп в качестве (обновляемого по запросу) ключа? Оригинально.

Ключи не имеют права обновляться - RTFM контракт для мапа. Но *кто* *мешает* *сделать* *свой* MapEntry c таймштампом ?!

>Плюс отдельный фоновый тред, проходящий по кэшу для убиения устаревших ключей

Это самый тупой солюшен из возможных - значит будет работать как часы.

>Ключи не имеют права обновляться - RTFM контракт для мапа.

Кто сказал? Не авторитет.

Если замапеный объект будет вынут из мапа (размапен), а потом снова замапен, то ключ должен быть изменён. Ага — во время мапирования объекта создаём ключ из таймштампа, и ссылка на объект в мапе получит второе дыхание. Конечно, после операции изымания объекта, можно уничтожить старый ключ (он не нужен), сократив работу фоновому треду, поработать с объектом и снова положить в кэш уже под новым ключом.

Когда объект в кэше естественным образом устареет, то фоновый тред уничтожит ключ и обнулит ссылку на объект — апплет при невозможности получения объекта из мапа создаст новый объект (загрузит из сети), поработает, создаст ключ-таймштамп, положит в кэш и т.д..

А чистить кеши, основываясь на, скажем, частоте использования ресурса, итд - сейчас в жабакоролевстве не модно? Все, значит, перекладывается на gc?

> Это самый тупой солюшен из возможных - значит будет работать как часы.

Честно говоря, мне трудно представить более простой солюшн, чем наличие 2 референсов -- слабого и мягкого. Ты же предлагаешь развести бухгалтерию, да еще и убивать что-то там по таймауту, а не по к-ву свободной памяти.

> А чистить кеши, основываясь на, скажем, частоте использования ресурса, итд - сейчас в жабакоролевстве не модно?

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

Вот я и вычислил в тебе быдлокодера не смотревшего исходники сабжа.

Там расписано почему www_linux_org_ru порет херню (и абсурд тоже) :)

И
>If you still want to implement a cache class that takes advantage of SoftReferences yourself, implement your own Map class that extends AbstractMap and internally wrap the map values in SoftReferences. Then you need to implement an internal mechanism to remove the stale entries from the map. For this, you may want to use a ReferenceQueue, and poll the ReferenceQueue for collected entries. Then, for each collected entry, you will need to remove it from the map. Make sure you do this in an efficient way! Or you may end up with some nested loops and O(n2) operations and your cache performance will suck.

Это уже интересно, однако.

Товарищи, хватит уже велосипеды строить. Если нужен кэш на софт/викреференсах, смотрите на jcache (fkcache) - он даже работает и исходники есть. Но как уже было сказано - в клиентской vm минимальная живучесть объектов не гарантирована. Может быть проще даже использовать в этой ситуации под кэш LRUMap, но для апплета ее придется писать самостоятельно.

> Там расписано почему www_linux_org_ru порет херню (и абсурд тоже)

Очередной высер без конкретной ссылки или цитаты. А свое решение ты так и не привел.

> Это уже интересно, однако.

Это *не дает* ответ на твой изначальный вопрос -- как ходить по софт референсам, не апдейтя таймштамп.

Про велосипеды я написал раньше, они нужны, и никакие жэ-какаши не подойдут. Кеш я сварганил, но что интересно, с softreference unit-test выдает heap space error (не хватает кучи), если ее тупо заменить на Weakrefernce то переполнить память уже не реально, но объекты не живут вообще (если ссылок на них нет). то есть описанное ранее поведение не соотв. реальности, однако ест ьвероятность что подгадили юнит тесты ибо выполнятся они могут со специфическим настройками jre.

Обычно такие штуки изучаются не юнит-тестами, а исследованиями снапшотов и выхлопов gc.

снапшоты и делались, но с юнит тестов. седня еще потестирую но обычном приложении.