Állandó memória területet, java specialista
Először is megjegyzem, hogy ez a terület nem szerepel a halom kiosztott -Xmx. Annak érdekében, hogy növelje a hangerő módszert kell alkalmaznia -XX: MaxPermSize. Lássuk, mi van tárolva ezen a területen, és ez ahhoz vezethet, hogy a túlcsordulás.
Metaadattárhoz tárgyak
A szempontból java ezen a területen azonos célokat, hogy a fő kupac. Csak azt, hogy bizonyos típusú objektumok, nevezetesen Class, Method, Field és kivitelező. Tudok felsorolni több oka a növekvő számú ilyen létesítmények.
1. A könyvtárak nyilvánvalóan generál bájtkódot
Tudom, legalább két könyvtárból, amely képes generálni bytecode: csúcspont és cglib. Csak most kezdődik a java 6, akkor most közvetlenül hívja a standard fordító. Általában a korábban is lehetett átjutni Runtime.getRuntime (). Exec (). Ha féktelen generál bytecode és betölti az új osztályok, előbb vagy utóbb, meg lehet vizsgálni egy OutOfMemoryError.
2. A java.lang.reflect.Proxy
Ez a szabvány JDK osztály generál, és betölti az új osztály. Azokat az osztályokat általában $ Proxy, ahol N - egész.
3. A könyvtárak hallgatólagosan generál bájtkódot
Hibernate, Spring, AspectJ, és sok más könyvtárak generálhat osztályok vagy használja a proxy dinamikus menet közben.
4. Java Reflection API
Nyilvánvaló, hogy a visszaverődés objektumok létrehozásához, mint a mező és módszer. amelyek a fent említettek tartoznak az állandó területet. De ez nem nyilvánvaló, hogy ismételt fellebbez minden osztályban területen keresztül reflexió, vagy hívja a módszer, létrehozott és letöltött egy új osztályt. A tény az, hogy mint optimalizálási úgy, hogy minden egyes alkalommal, hogy nem kívánnak a váltás a táblázatban, ahol az adatok mezők, a JVM generál különleges osztályok felgyorsítja ezt a folyamatot. Ezeket nevezik általában GeneratedMethodAccessor, GeneratedFieldAccessor, GeneratedConstructorAccessor ahol - egész. Természetesen ez a viselkedés függ a végrehajtás a JVM, és nem meghatározott, de abban a pillanatban HotSpot JVM igen.
5. sorszámozás
Ha a standard java serialization segítségével tükrözi. Ezzel szól JVM mezőben serialVersionUID. ellenőrzéseket writeObject módszer. keresi az összes mezőt az osztályban, ha nem szorítja writeObject beolvassa az alapszerkezet. Tipp itt egyértelmű: ne használja a Serializable felületen. Legalább nézd meg a döntést Externalizable. Bár én mostanában inkább protokollbufferekkel. mint egy kereszt-platform megoldást.
Mint tudja, RMI aktívan használja sorszámozás, így ismét megszerezni tükrözi az összes ezt követő hatásokat.
Class adatmegosztás (CDS)
A java 5 volt olyan dolog, mint a CDS. Ez egy file, amely része a JVM tartalmazó telepítés dapm JVM memória, amely a betöltött osztályok magját alkotó JVM, azaz meggyőződtek arról, hogy a JVM volna letölteni azonnal induláskor. Van egy ilyen területen, akkor azonnal mapitsya inicializálás java gép, ezáltal felgyorsítja a dob alkalmazást. Ahogy talán már sejtette, ezen a területen is beleesik az állandó területet. Sőt, ez tartalmazza az összes azonos osztályú objektumok osztályba, csak kirak őket, és törölje a JVM memória nem.
húr medence
Szemétgyűjtés a PermGen
Amikor az emberek beszélnek a szemétgyűjtő, annál gyakrabban ez a terület kijelölt PermGen. Név szerint, úgy tűnik, hogy a létrehozott objektumokat ezen a területen soha nem tisztította. De nem minden és nem mindig.
Például, string interning soha tisztítani. Mivel abban az esetben, CDS, állandó régiót két részre van osztva: csak olvasható és írható-olvasható. Nyilvánvaló, hogy ebben az esetben a terület az írásvédett nem tiszta a szemétgyűjtő.
Diagnosztizálni nagyszámú osztály betöltése problémát, és ellenőrizze, hogy azok terheletlen, vagy nem, akkor a következő lehetőségek JVM
Engedélyezése / tiltása kirakodását osztályok, akkor a paramétereket
Ha egy kis szünet szemétgyűjtő (CMS), hogy lehetővé tegye az egységet a PermGen, be kell állítania két paramétert (legalábbis java 5 kellett, hogy biztos, hogy tartalmazza az opciók, vagy nem működik)