öt titok

Erről a sorozat

Azt hiszed, hogy Java-programozás az egész? Tény, hogy a fejlesztők többsége csak a felszínt, a Java platform, vizsgálja meg csak annyi, hogy végezzék munkájukat. Ebben a sorozatban, Ted Neward mélyebbre a funkcionalitást a Java platform képességeit, és felfedi a kevésbé ismert tényeket, amelyek segíthetnek megoldani a legkomplikáltabb programozás.

JVM - egy igásló, amely a funkciókat és Java-alapú alkalmazások és a legtöbb Java-fejlesztő biztosra veszi. És nagyon kevés ember igazán értem, hogyan működik JVM, mit csinál - olyan dolgok, mint a tárgyak elosztása és szemétgyűjtő telepítési áramlás, fájlok megnyitása és zárása, értelmezésével és / vagy a JIT-fordítani a Java byte-kód, és így tovább.

A tudatlanság a JVM költséges a alkalmazások teljesítményét, és ha valami elromlik, akkor nagyon megnehezítené kísérletet, hogy orvosolja a helyzetet.

1. DisableExplicitGC

Készségek fejlesztése ebben a témában

Ez az anyag - része a tudás útját a fejlődését a képességeit. Lásd a cikket Java-programozó

Nem tudom megmondani, hogy hány alkalommal, amikor felkérték, hogy adjon tanácsot a probléma az alkalmazások teljesítményét, gyors grep kód azt mutatja, mi látható az 1. lista - klasszikus antimodelyu Java teljesítményét.

1. lista System.gc ();

Ahhoz azonban, hogy ezen speciális probléma megoldására Sun mérnökei biztosította számunkra egy speciális JVM-zászló. A zászló -XX: + DisableExplicitGC automatikusan bekapcsolja System.gc () hívást a no-op, így a fejlesztő képes futtatni kódot, és ellenőrizze, ha ez segít System.gc () művelet vagy fáj JVM teljesítmény egészére.

Az IBM JVM ugyanazt a funkciót, amely elérhető a JVM alapján HotSpot technológia alkalmazásával lehet végezni az eredmény -Xdisableexplicitgc csapat.

2. HeapDumpOnOutOfMemoryError

Előfordult már tapasztalni, mint nap, amikor a JVM van hajlítva, így OutOfMemoryError üzeneteket. de nem lehet kényszeríteni a hibakereső fogni az oka? Az ilyen szórványos vagy nem determinisztikus probléma csökkenthető Fejlesztő őrült.

legyen éber

Nem minden a parancssori zászlók feltétlenül támogatott VM, kivéve, ha a Sun / Oracle. A legjobb módja annak megállapítására, hogy a zászló természetesen támogatja - próbálja ki, és nézd meg, hogy működik-e. Ha azonban ezek a zászlók nem támogatja technikailag, kizárólag Ön a felelős a használatukra. Sem én, sem a Sun / Oracle, IBM, vagy nem lesz felelős, hogy ennek eredményeképpen ezek bármelyikének zászlók eltűnt a kód, az adatok szerver, vagy az anyád. Elővigyázatosságból azt tanácsolom, hogy először próbálja ki őket egy virtuális (nem termelési) környezetben.

Ilyen esetekben van szükség, hogy egy pillanatképet a halom jobbra a pillanat, amikor a JVM bocsát szellem - és ez az, ami egy csapat -XX: + HeapDumpOnOutOfMemoryError.

Mert ez a csapat teszi a JVM „hányó billenő pillanatfelvétel”, és elmenti egy fájlba további feldolgozás céljából, jellemzően jhat segédprogram (amit be egy korábbi cikkben). Az út, amely menti a fájlt, meg lehet egy megfelelő zászló -XX: HeapDumpPath. (Ahol menteni a fájlt, győződjön meg róla, a fájlrendszer és / vagy Java folyamatot a szükséges konfigurációs engedélyeket kell írni, hogy ott van.)

A mechanizmus a JVM IBM billenő ez a funkció alapértelmezés szerint engedélyezve van, biztosítva, hogy Ön heapdump jelenlétében egy OutOfMemoryError. IBM billenő mechanizmus számos olyan konfigurációs paramétereket, beleértve a tiltó guba a parancssori paraméterek -Xdump.

3. bootclasspath

Érdemes rendszeresen küld az osztály az úton classpath, ami kissé eltér a mellékelt JRE, vagy valamilyen módon kiterjeszti a JRE. (Egy példa lenne az új szolgáltató Java Crypto API). Ha azt szeretnénk, hogy meghosszabbítja a JRE, akkor a speciális végrehajtási rendelkezésre kell állnia a ClassLoader rakodó. betölti java.lang.Object és kollégái a rt.jar.

Bár lehet nyitni rt.jar és adja, hogy egy speciális változata az új csomagot, vagy lenne technikailag ez sérti az engedély, amely elfogadta, hogy ha letölti a JDK.

Ehelyett használja a saját beállítás JVM -Xbootclasspath és rokonai -Xbootclasspath / p és -Xbootclasspath / a.

-Xbootclasspath lehetővé teszi, hogy adja meg a teljes elérési út indító classpath, amelyek tipikusan tartalmaz egy linket rt.jar. plusz egy csomó más JAR-fájl tartalmazza a JDK és nem része rt.jar. -Xbootclasspath / p hozza az értéket elején meglévő változó bootclasspath és -Xbootclasspath / a - a végén.

Ha például megváltoztatja a tömb java.lang.Integer és módosította az alkönyvtár mod. A paraméter -Xbootclasspath / a mod fog alakítani egy új értéket Egész alapértelmezés szerint.

4. bőbeszédű

-bőbeszédű - egy hasznos első szintű diagnosztikai eszköz a Java-alapú alkalmazások gyakorlatilag bármilyen típusú. Ez a zászló három podflaga: gc. osztály és JNI.

gc általában az első, hogy vegye igénybe, amit a fejlesztők, hogy megpróbálja kideríteni, hogy rossz JVM szemétgyűjtő, és nem volt, hogy ez az oka a gyenge teljesítmény. Sajnos, értelmezése gc kiadási nehéz lehet - olyannyira, hogy lehetséges, hogy írjon egy egész könyvet. Még rosszabb, hogy az adatok jelennek meg a parancssorban, megváltoztathatja az egyik megjelenése Java a másikba vagy egyik JVM a másikra, ami tovább bonyolítja a helyes értelmezés.

Általánosságban elmondható, hogy ha a szemétgyűjtő alapul a „generációk tárgyak” (mint például a VM «nagyvállalati” többség), vagy hogy egy jól látható zászló jelzi a teljes furat GC; JVM Sun néz ki zászló [Full GC. ] GC elején az output string.

osztály lehet életmentő, amikor próbálják diagnosztizálni ClassLoader vagy konfliktusok az osztályok közötti különbséget. Ez azt jelzi, nem csak az osztály rakodási idő, hanem egy hely, ahol volt letölthető, beleértve az elérési utat a JAR fájlt, ha jött az üveget.

JNI csak akkor hasznos, ha dolgozik, JNI és saját könyvtárak. Ha engedélyezve van, akkor jelenti JNI különféle események, mint például a berakodás időpontjában a saját könyvtárak és kötelező módszerek; Ismét, az eredmény változhat egy felszabadulást, hogy a következő egy vagy a másik JVM.

5. Command-line -X

Van felsorolt néhány kedvenc parancssori opciókról a JVM, de sok közülük, hogy az olvasó el kell végeznie a saját vizsgálatot. Fuss egy parancssori argumentum X vezet át az összes nem szabványos (de főleg a biztonságos) érveiket JVM - például:

-Xint. amely ellátja a JVM értelmezni mód (hasznos lehet ellenőrizni, hogy a JIT-fordító kódot hatással van, és nincsenek hibák benne);
-Xloggc. ami nem ugyanaz, mint a -verbose: gc. de a rekord a fájl, hanem rájuk dobott a parancssor ablakot.

JVM időről időre módosítsa a parancssori paramétereket, így érdemes rendszeresen felülvizsgálja azokat. Függhet attól, hogy hosszú órákon át a monitor, vagy menj haza 17:00 és képes lesz vacsorázni a feleségével és a gyerekek (vagy ölni ellenségei a Mass Effect 2, tetszése szerint).

A JVM IBM eredmény kiadási bőbeszédű: gc egy fájl kérelmezni -Xverbosegclog paramétert. amely lehetővé teszi, hogy hozzon létre egy log fájlt leírás.

következtetés

parancssori jelzők nem folyamatos használatra termelési környezetben - sőt, amellett, hogy a zászlókat, hogy (valószínűleg) a végén segítségével beállítani a szemétgyűjtő JVM, sem a nem szabványos parancssoros zászló nem éles használatra szánták. De ezek felbecsülhetetlen értékű, mint egy eszköz, hogy belenézel futó virtuális gép, amely más esetekben teljesen átlátszatlan.