Acest articol este despre tehnici pe care le-am folosit pentru depanarea bazelor de coduri de diferite tipuri, cum ar fi:

  1. CodeBase cu caracter concurent ridicat.
  2. CodeBase cu o mulțime de biblioteci proprietare (neacceptate).
  3. CodeBase cu o mulțime de cod depreciat / nedorit.
  4. CodeBase cu scurgeri de memorie.
  5. CodeBase în care fiecare JVM poate vorbi cu orice altă JVM.

Deci, să le privim pe rând.

CodeBase cu caracter concurent ridicat.

Se poate întâmpla ca pentru servirea unei cereri, JVM să folosească mai multe fire de ex.

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

Să zicem, descoperim că excepția vine în BizThread-3. Acum, ca depanator, vrem să înțelegem fluxul de solicitări. Dar stacktrace nu va putea furniza fluxul complet de cereri (de exemplu, ce s-a întâmplat în executorThread-2 și ce s-a întâmplat în tomcatThread-1 si asa mai departe).

Tehnica 1.1: Scrie o agent java personalizat care va fi folosit pentru a adăuga în mod eficient log.debug() la începutul și sfârșitul fiecărei metode a anumitor pachete Java. Acest lucru ne va oferi o perspectivă asupra a ceea ce se numește totul.

Tehnica 1.2: În anumite cadre, dacă este acceptat, utilizați AOP pentru a procura toate metodele și a adăuga în mod eficient log.debug().

CodeBase cu o mulțime de biblioteci proprietare (neacceptate).

Uneori ne găsim într-o situație în care, după ore de depanare, punem problema xyz-gov-secret biblioteca se comportă greșit și această bibliotecă este acum neacceptată.

Tehnica 2.1: Ridicați-vă mânecile și instalați eclipsă-decompilator și scufundați-vă în baza codului.

CodeBase cu o mulțime de cod depreciat / nedorit.

Acesta este unul clasic: uneori ne găsim într-o metodă de peste 500 de linii cu tone de altfel depreciat. Acum, cum ne dăm seama care este fluxul de cod pentru un anumit apel, care dacă-altfel vor folosi și care este codul mort?

Tehnica 3.1: Putem folosi un instrument numit agent jacoco. Colectează detaliile de execuție în timpul runtime-ului și poate codifica în culori codul în eclipse.
Practic, este același instrument, utilizat în general în analiza acoperirii codului prin testul JUnit.

CodeBase cu scurgeri de memorie.

Fiecare dezvoltator are o zi în care, în sistemul lor local, totul merge bine, în producție OutOfMemory 🙁

Tehnica 4.1: JVM oferă tehnici pentru a captura depozite de heap în caz de outOfMemory.

Adăugați următoarele ca argument în timp ce porniți JVM
-XX: + HeapDumpOnOutOfMemoryError . Aceasta va captura depozitul de heap și îl va pune într-un fișier, care poate fi folosit pentru a analiza ceea ce consumă memoria.

Tehnica 4.2: De asemenea, puteți lua hump dump / thread dump a unei JVM care rulează folosind jProfiler/Jvisiualvm.

CodeBase în care fiecare JVM poate vorbi cu orice altă JVM.

Când sunteți aruncat într-un mediu distribuit de spaghete, devine dificil să urmăriți fluxul de solicitări.

Tehnica 5.1: Puteți utiliza instrumente precum Wireshark. Wireshark captează datele de rețea și le reprezintă într-o interfață grafică. Apoi, puteți vizualiza cererea / răspunsul HTTP care curge prin sistem

Mentiuni onorabile

Tehnica 6.1: Într-un mediu cu un singur fir, introduceți intenționat
try catch pentru a cunoaște rapid stâlpul.

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

Tehnica 6.2: Utilizarea punctului de întrerupere eclipsă sau utilizarea punctului de întrerupere condiționat.

Tehnica 6.3: https://en.wikipedia.org/wiki/Rubber_duck_debugging

Motivația articolului: Învățarea în echipă / Partajarea cunoștințelor.