Min foretrukne Java-fejlretningsteknik

Denne artikel handler om teknikker, som jeg har brugt til at debugge codeBases af forskellige slags, såsom:

  1. CodeBase med høj samtidig karakter.
  2. CodeBase med mange proprietære (ikke-understøttede) biblioteker.
  3. CodeBase med en masse forældet / uønsket kode.
  4. CodeBase med hukommelseslækage.
  5. CodeBase, hvor hver JVM kan tale med enhver anden JVM.

Så lad os se på dem en efter en.

CodeBase med høj samtidig karakter.

Det kan ske, at JVM til servering af en anmodning bruger mange tråde til f.eks .:

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

Lad os sige, vi finder ud af, at undtagelsen kommer i BizThread-3. Nu som debugger ønsker vi at forstå anmodningsflowet. Men stacktrace vil ikke være i stand til at levere den komplette anmodningsstrøm (for eksempel hvad der skete i executorThread-2 og hvad der skete i tomcatThread-1 og så videre).

Teknik 1.1: Skriv en brugerdefineret java-agent, som vil blive brugt til effektivt at tilføje log.debug()til starten og slutningen af ​​hver metode til bestemte java-pakker. Dette vil give os et indblik i, hvad alt bliver kaldt.

Teknik 1.2: I visse rammer, hvis det understøttes, skal du bruge AOP til at proxy alle metoder og effektivt tilføje log.debug().

CodeBase med mange proprietære (ikke-understøttede) biblioteker.

Nogle gange befinder vi os i en situation, hvor vi efter timers debugging sømmer det problem, at xyz-gov-hemmeligt bibliotek opfører sig forkert, og dette bibliotek understøttes nu ikke.

Teknik 2.1: Rul ærmerne op, og installer eclipse-decompilerog dykke ned i kodebasen.

CodeBase med en masse forældet / uønsket kode.

Dette er en klassisk: vi befinder os nogle gange i en metode til 500+ linjer med tonsvis af udfaset hvis-ellers. Nu, hvordan finder vi ud af, hvad der er kodestrømmen for et bestemt opkald, som hvis ellers skal bruge, og hvilken er den døde kode?

Teknik 3.1: Vi kan bruge et værktøj kaldet jacoco agent . Det indsamler udførelsesoplysningerne under løbetid og kan farvekode koden i formørkelse.

Dybest set er det det samme værktøj, der generelt bruges til at analysere kodedækning ved JUnit Test.

CodeBase med hukommelseslækage.

Hver udvikler har en dag, hvor alt i deres lokale system går godt, i produktionen OutOfMemory :(

Teknik 4.1:JVM leverer teknikker til at fange bunke dumps i tilfælde af outOfMemory.

Tilføj følgende som et argument, mens du starter JVM

-XX: + HeapDumpOnOutOfMemoryError . Dette fanger bunke-dumpen og lægger den i en fil, som kan bruges til at analysere, hvad der spiser hukommelsen.

Teknik 4.2: Du kan også tage heap dump / thread dump af en kørende JVM ved hjælp af jProfiler / Jvisiualvm.

CodeBase, hvor hver JVM kan tale med enhver anden JVM.

Når du smides i et spaghettidistribueret miljø, bliver det svært at spore anmodningsflowet.

Teknik 5.1: Du kan bruge værktøjer som Wireshark . Wireshark registrerer netværksdataene og repræsenterer dem i et flot brugergrænseflade. Du kan derefter se HTTP-anmodningen / svaret, der flyder gennem systemet

Ærlige omtaler

Teknik 6.1: Indsæt bevidst i et enkelt trådmiljø

try catch for hurtigt at kende stacktrace.

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

Teknik 6.2: Brug af formørkelsesbrudpunkt eller brug af betinget brudpunkt.

Teknik 6.3: //da.wikipedia.org/wiki/Rubber_duck_debugging

Motivation af artiklen: Team Learning / Knowledge Sharing.