Проблемы с производительностью гибернации и утечкой памяти в профилировщике

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

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

Хеш-карта объектов на экране с записанными объектами увеличилась почти до 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();
}

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


java hibernate memory-leaks hibernate-criteria jprofiler
person R. Rahul    schedule 26.04.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

person duffymo    schedule 26.04.2011
comment
Eclipse также генерирует вполне пригодные для использования реализации equals и hashCode :) - person Thomas; 26.04.2011
comment
@ duffymo, спасибо, я прочитал тему и да, я обнаружил, что у EqualsBuider есть некоторые проблемы с производительностью. Есть ли у вас какие-либо идеи о списке гибернации, поиске и критериях. - person R. Rahul; 26.04.2011

arrow_upward
0
arrow_downward

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

person Thomas    schedule 26.04.2011
comment
нет, я так не думаю, утечка памяти отличается от потребления памяти. Если в вашем приложении есть проблема с утечкой памяти, это означает, что вы не можете освободить память даже после того, как сборщик мусора выполнил свою работу. Это из-за некоторых ссылок, оставленных в некоторых используемых объектах, которые ограничивают выполнение GC своей работы. - person R. Rahul; 26.04.2011
comment
@Кури Это правда. Однако я не совсем уверен, действительно ли OP обнаружил утечку памяти (неиспользуемые объекты, на которые все еще ссылаются каким-то образом и, следовательно, не могут быть собраны) или просто высокое потребление памяти. - person Thomas; 26.04.2011
comment
я тоже не очень уверен, но написано, что если график телеметрии vm движется вверх, то это означает, что есть утечка памяти. Даже если вы вызовете GC, он не уверен, что GC выполнит свою работу. Может быть, этот объект остался в памяти и через какое-то время освободился. - person R. Rahul; 26.04.2011
comment
Но новый объект находится в области действия метода и должен подходить для GC каждый раз, когда код выходит из equals и hashCode. Возвращаемый элемент является продуктом связанных вызовов из интерфейса Fluent, а не самого нового объекта. Это было бы действительно серьезной проблемой. - person duffymo; 26.04.2011