Проблеми с производителността на хибернация и изтичането на памет при профилиране

Профилирах моето J2EE уеб приложение с помощта на jprofiler. Открих, че има огромно изтичане на памет, като погледнах vm телеметричната графика и записания обект. Използвайки heap walker, заключавам, че има много изтичане на памет поради критериите за хибернация, 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();
}

Благодаря много.


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

Отговори (2)


arrow_upward
3
arrow_downward

EqualsBuilder използва отражение, което може да има въздействие върху perm gen space.

Защо да разчитате на тях? Защо просто не ги напишете сами? Ако използвате 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. Това може да доведе до по-висока консумация на памет, ако GC не стартира или не събере тези обекти. Имате ли проблеми с паметта поради това?

person Thomas    schedule 26.04.2011
comment
не, не мисля така, изтичането на памет е различно от потреблението на памет. Ако вашето приложение има проблем с изтичане на памет, това означава, че не можете да освободите паметта дори след като GC е свършил работата си. Това се дължи на някои препратки, останали в някои използвани обекти, които ограничават GC да върши работата си. - person R. Rahul; 26.04.2011
comment
@Kuri Това е вярно. Въпреки това не съм съвсем сигурен дали OP наистина е открил изтичане на памет (неизползвани обекти, които все още са посочени по някакъв начин и следователно не могат да бъдат събрани) или просто висока консумация на памет. - person Thomas; 26.04.2011
comment
Аз също не съм много сигурен, но е написано, че ако vm телеметричната графика се движи нагоре, това означава, че има изтичане на памет. Тъй като дори да се обадите на GC, не е сигурно, че GC изпълнява работата си. Може ли този обект да остане в паметта и след известно време да бъде освободен. - person R. Rahul; 26.04.2011
comment
Но новият обект е в обхвата на метода и трябва да отговаря на условията за GC всеки път, когато кодът излезе от equals и hashCode. Елементът, който се връща, е продукт на верижните извиквания от плавния интерфейс, а не самият нов обект. Това наистина би било сериозен проблем. - person duffymo; 26.04.2011