Java: какие-либо проблемы / отрицательные стороны сохранения SoftReference для ArrayList в HttpSession?
Мой код выполняет следующее (просто в качестве примера, и причина, по которой я указываю путь пакета к java.lang.ref.SoftReference, состоит в том, чтобы отметить, что это не моя собственная реализация:-):
...
List<String> someData = new ArrayList<String>();
someData.add("Value1");
someData.add("Value2");
...
java.lang.ref.SoftReference softRef = new SoftReference(someData);
...
HttpSession session = request.getSession(true);
session.setAttribute("mySoftRefData", softRef);
...
и позже:
...
java.lang.ref.SoftReference softRef = session.getAttribute("mySoftRefData");
if (softRef != null && softRef.get() != null) {
List<String> someData = (List<String>)softRef.get();
// do something with it.
}
...
Есть ли недостатки? Которого я не вижу? Спасибо!
3 ответа
Очевидным недостатком является то, что список может исчезнуть непредсказуемо. Поскольку сеанс является мусором после истечения срока его действия, я не вижу варианта использования SoftReference. Если список становится значительно большим (по крайней мере, достаточно значительным, чтобы оправдать использование SoftReference), я бы предпочел другое хранилище (БД, временные файлы).
Если вы не ссылаетесь на него где-либо еще в коде, а JVM запустила сборщик мусора, вы можете рискнуть, что ссылка больше не будет в сеансе. Однако шансов мало, меньше, чем при использовании слабой ссылки, но, тем не менее, она есть.
Я бы не стал делать это в веб-приложении. Если это чистые данные в рамках сеанса (например, вошедший в систему пользователь, корзина и т. Д.), Просто поместите их в область сеанса обычным способом. Если сеанс истекает или становится недействительным, то все, на что нет ссылок нигде, будет собираться мусором в любом случае. Область действия сеанса не предназначена для использования в качестве "мягкого" кэша. Или, если это на самом деле данные в области запроса, лучше сохранить их в области запроса. Еще используйте другой тип хранилища данных.
Это очень хорошая идея, чтобы поместить данные, которые не являются на 100% необходимыми для приложения, в одноразовый кеш. В часы пик они будут сброшены, что позволит сэкономить больше ресурсов для более насущных потребностей.
Путь, короче.