Kedvenc Java hibakeresési technikáim

Ez a cikk azokról a technikákról szól, amelyeket a kódbázisok különféle hibakeresésére használtam, például:

  1. CodeBase nagy egyidejűleg.
  2. CodeBase sok saját (nem támogatott) könyvtárral.
  3. CodeBase sok elavult / nem kívánt kóddal.
  4. CodeBase memóriaszivárgásokkal.
  5. CodeBase, ahol minden JVM beszélhet minden más JVM-mel.

Nézzük tehát őket egyenként.

CodeBase nagy egyidejűleg.

Előfordulhat, hogy egy kérés kiszolgálásához a JVM sok szálat használ, például:

Req -> tomcatThread-1 -> executorThread-2 -> BizThread-3->…`

Mondjuk úgy látjuk, hogy a BizThread-3-ban ez a kivétel jön. Most hibakeresőként meg akarjuk érteni a Request folyamatot. De a stacktrace nem tudja biztosítani a teljes kérési folyamatot (például mi történt a végrehajtóThread-2-ben és mi történt a tomcatThread-1-ben stb.).

1.1. Technika: Írjon egy egyedi java-ügynököt, amellyel hatékonyan hozzá log.debug()lehet adni egyes java csomagok minden módszerének elejéhez és végéhez. Ez némi betekintést nyújt abba, hogy mi mindent hívnak.

1.2. Technika: Bizonyos keretrendszerekben, ha támogatottak, használja az AOP-t az összes módszer proxy-hoz és hatékony hozzáadásához log.debug().

CodeBase sok saját (nem támogatott) könyvtárral.

Néha olyan helyzetbe kerülünk, hogy órákon át tartó hibakeresés után azt a problémát szögezzük le, hogy az xyz-gov-secret könyvtár rosszul viselkedik, és ez a könyvtár már nem támogatott.

2.1. Technika: Tekerje fel az ujját, és telepítse az eclipse-decompiler programotés belemerül a kódbázisba.

CodeBase sok elavult / nem kívánt kóddal.

Ez egy klasszikus: néha 500 + soros módszerrel találjuk magunkat, rengeteg elavult ha-mással. Most hogyan derítsük ki, hogy mi a kódfolyama egy adott hívásnak, melyiket használjuk-e, és melyik a holt kód?

3.1. Technika: Használhatunk Jacoco agent nevű eszközt . Futás közben összegyűjti a végrehajtás részleteit, és az eclipse-ben színkódolni tudja a kódot.

Alapvetően ugyanaz az eszköz, amelyet általában a JUnit Test által végzett kód lefedettségének elemzésére használnak.

CodeBase memóriaszivárgásokkal.

Minden fejlesztőnek van egy napja, amikor a helyi rendszerükben minden jól megy, az OutOfMemory produkcióban :(

4.1. Technika:A JVM technikákat kínál a kupaclerakatok rögzítésére outOfMemory esetén.

Adja hozzá a következőket argumentumként a JVM indításakor

-XX: + HeapDumpOnOutOfMemoryError . Ez rögzíti a kupacdumpot, és egy fájlba teszi, amellyel elemezni lehet, hogy mi emészti fel a memóriát.

4.2. Technika: A futó JVM kupac / szál kiírását is megteheti a jProfiler / Jvisiualvm segítségével.

CodeBase, ahol minden JVM beszélhet minden más JVM-mel.

Ha egy spagettivel elosztott környezetbe kerül, nehézkessé válik a kérésfolyam felkutatása.

5.1. Technika: Használhat olyan eszközöket, mint a Wireshark . A Wireshark rögzíti a hálózati adatokat, és szép felhasználói felületen ábrázolja. Ezután megtekintheti a rendszeren keresztül áramló HTTP kérést / választ

Említésre méltóak

6.1. Technika: Egyszálas környezetben szándékosan illessze be

try catch a stacktrace gyors megismerése érdekében.

try { throw new RuntimeException(); } catch(Exception e){ e.printStackTrace(); }

6.2. Technika: Eclipse töréspont vagy feltételes töréspont használata.

6.3. Technika: //hu.wikipedia.org/wiki/Rubber_duck_debugging

A cikk motivációja: Csapattanulás / Tudásmegosztás.