Ovaj članak govori o tehnikama koje sam koristio za otklanjanje pogrešaka kodova različitih vrsta, kao što su:
- CodeBase s visokom istodobnom prirodom.
- CodeBase s puno vlastitih (nepodržanih) knjižnica.
- CodeBase s puno zastarjelog / neželjenog koda.
- CodeBase s curenjem memorije.
- CodeBase gdje svaki JVM može razgovarati sa svakim drugim JVM-om.
Pa pogledajmo ih jedan po jedan.
CodeBase s visokom istodobnom prirodom.
Može se dogoditi da za posluživanje zahtjeva JVM koristi mnoge niti za npr.
Req -> tomcatThread-1 -> executorThread-2 -> BizThread-3->…`Recimo, otkrivamo da iznimka dolazi u BizThread-3. Sada kao program za ispravljanje pogrešaka želimo razumjeti tijek zahtjeva. Ali stacktrace neće moći pružiti cjelovit tijek zahtjeva (na primjer, što se dogodilo u executorThread-2 i što se dogodilo u tomcatThread-1 i tako dalje).
Tehnika 1.1: Napišite prilagođeni java-agent koji će se koristiti za učinkovito dodavanje log.debug()na početak i kraj svake metode određenih java paketa. To će nam dati uvid u to što se sve naziva.
Tehnika 1.2: U određenim okvirima, ako su podržani, upotrijebite AOP za proksiranje svih metoda i učinkovito dodavanje log.debug().
CodeBase s puno vlastitih (nepodržanih) knjižnica.
Ponekad se nađemo u situaciji da, nakon višesatnog otklanjanja pogrešaka, zakuvamo problem u tome što se xyz-gov-secret knjižnica loše ponaša i ova knjižnica sada nije podržana.
Tehnika 2.1: zasučite rukave i instalirajte eclipse-decompileri zaronite u bazu koda.
CodeBase s puno zastarjelog / neželjenog koda.
Ovo je klasično: ponekad se nađemo u metodi od 500+ redaka s tonama zastarjelih if-else. Sada, kako da shvatimo koji je protok koda za određeni poziv, koji će if-else koristiti, a koji mrtvi kôd?
Tehnika 3.1: Možemo koristiti alat koji se naziva jacoco agent . Prikuplja detalje izvršenja tijekom izvođenja i može kodirati kod u boji u eclipseu.
U osnovi, to je isti alat, koji se obično koristi za analizu pokrivenosti koda pomoću JUnit testa.
CodeBase s curenjem memorije.
Svaki programer ima dan kada u njihovom lokalnom sustavu sve ide u redu u proizvodnji OutOfMemory :(
Tehnika 4.1:JVM pruža tehnike za hvatanje deponija hrpe u slučaju outOfMemory.
Dodajte sljedeće kao argument tijekom pokretanja JVM-a
-XX: + HeapDumpOnOutOfMemoryError . Ovo će zabilježiti odlagalište hrpe i staviti ga u datoteku koja se može koristiti za analizu onoga što jede memoriju.
Tehnika 4.2: Također možete izvršiti dump heap / dump niti pokrenute JVM koristeći jProfiler / Jvisiualvm.
CodeBase gdje svaki JVM može razgovarati sa svakim drugim JVM-om.
Kada vas bace u okruženje distribuiranog špageta, postaje teško pratiti tijek zahtjeva.
Tehnika 5.1: Možete koristiti alate poput Wiresharka . Wireshark bilježi mrežne podatke i predstavlja ih u lijepom korisničkom sučelju. Tada možete vidjeti HTTP zahtjev / odgovor koji prolazi kroz sustav
Časna spomena
Tehnika 6.1: Namjerno umetnite u okruženje s jednim navojem
try catch kako bi se brzo saznao trag stoga.
try { throw new RuntimeException(); } catch(Exception e){ e.printStackTrace(); }Tehnika 6.2: Korištenje točke prekida pomrčine ili korištenja uvjetne točke prekida.
Tehnika 6.3: //en.wikipedia.org/wiki/Rubber_duck_debugging
Motivacija članka: Timsko učenje / razmjena znanja.