Проблемы с производительностью в спящем режиме и утечкой памяти под профилировщиком - PullRequest
2 голосов
/ 26 апреля 2011

Я профилировал свое веб-приложение J2EE с помощью jprofiler. Я обнаружил огромную утечку памяти, посмотрев на график телеметрии и записанный объект. Используя обходчик кучи, я пришел к выводу, что существует большая утечка памяти из-за критериев гибернации, query.list, template.find, переопределения метода hashCode и equals, а также в некоторых пользовательских обработчиках запросов. То, что я не могу понять, это то, как может быть утечка памяти.

Я много проверял в Google, и понятно, что критерии медленнее, чем HQL, и, очевидно, чем SQL, но утечка памяти довольно интересна. Есть ли вероятность утечки памяти?

При отображении объектов на экране объектов hashmap увеличилось почти до 100%, а график утечки памяти увеличился.

Я также показываю вам мой хэш-код и эквивалент метола, пожалуйста, посмотрите:

public boolean equals(Object other) {
    if ( !(other instanceof Associate) ) return false;
    Associate castOther = (Associate) other;
    return new EqualsBuilder()
        .append(this.getAssociateId(), castOther.getAssociateId())
        .isEquals();
}

public int hashCode() {
    return new HashCodeBuilder()
        .append(getAssociateId())
        .toHashCode();
}

Большое спасибо.

Ответы [ 2 ]

3 голосов
/ 26 апреля 2011

EqualsBuilder использует отражение, которое может оказать влияние на пространство перманента .

Зачем полагаться на них? Почему бы просто не написать их самому? Если вы используете IntelliJ, он сгенерирует методы, которые будут работать идеально без каких-либо изменений. Следуйте рецепту Джошуа Блоха , и у вас тоже будет меньше зависимости.

0 голосов
/ 26 апреля 2011

Ну, вы создаете новый объект при каждом вызове equals или hashCode. Это может привести к более высокому потреблению памяти, если ГХ не запускает и не собирает эти объекты. У вас проблемы с памятью из-за этого?

...