streamalism.org

1. Oversigt

I denne vejledning ser vi på nogle avancerede IntelliJ-fejlfindingsfaciliteter.

Det antages, at grundlæggende fejlretning allerede er kendt (hvordan man starter fejlretning, Træder ind, Træd over handlinger osv.). Hvis ikke, henvises til denne artikel for flere detaljer om det.

2. Smart Step Into

Der er situationer, hvor flere metoder kaldes på en enkelt kildekodelinje, f.eks doJob (getArg1 (), getArg2 ()). Hvis vi ringer Træder ind handling (F7), debugger går ind i metoderne i den rækkefølge, der bruges af JVM til evaluering: getArg1 – getArg2 – doJob.

Imidlertid, Vi vil måske springe alle mellemliggende opkald over og gå direkte til målmetoden. Smart Step Into handling tillader at gøre det.

Det er det bundet til Skift + F7 som standard og ser sådan ud, når den påberåbes:

Nu kan vi vælge målmetoden for at fortsætte. Bemærk også, at IntelliJ altid sætter den yderste metode øverst på listen. Det betyder, at vi hurtigt kan gå til det ved at trykke på Skift + F7 | Gå ind.

3. Slip ramme

Vi kan indse, at noget behandling, vi er interesseret i, allerede er sket (f.eks. Beregningen af ​​det nuværende metodargument). I dette tilfælde, det er muligt at droppe de aktuelle JVM-stakramme (r) for at genbehandle dem.

Overvej følgende situation:

Antag, at vi er interesserede i fejlretning getArg1 behandling, så vi taber den aktuelle ramme (doJob metode):

Nu vi er i den foregående metode:

Opkaldsargumenterne er imidlertid allerede beregnet på dette tidspunkt, så Vi er også nødt til at droppe den aktuelle ramme:

Nu kan vi køre behandlingen igen ved at ringe Træder ind.

4. Markbrudpunkter

Nogle gange ændres ikke-private felter af andre klasser, ikke gennem settere, men direkte (det er tilfældet med tredjepartsbiblioteker, hvor vi ikke kontrollerer kildekoden).

I sådanne situationer kan det være svært at forstå, hvornår ændringen er udført. IntelliJ giver mulighed for at oprette breakpoint på feltniveau for at spore det.

De indstilles som sædvanligt - venstreklik på den venstre redigeringsrender på feltlinjen. Derefter er det muligt at åbne egenskaber for breakpoint (højreklik på breakpoint-mærket) og konfigurer, om vi er interesserede i feltets læser, skriver eller begge dele:

5. Logning af breakpoints

Nogle gange ved vi, at der er en race-tilstand i applikationen, men ved ikke, hvor den er nøjagtigt. Det kan være en udfordring at sømme det ned, især når du arbejder med ny kode.

Vi kan tilføje fejlretningserklæringer til vores programs kilder. Der er dog ingen sådan mulighed for tredjepartsbiblioteker.

IDE kan hjælpe her - det giver mulighed for at indstille breakpoints, der ikke blokerer for udførelse, når de først er ramt, men i stedet producerer loggingssætninger.

Overvej følgende eksempel:

public static void main (String [] args) {ThreadLocalRandom random = ThreadLocalRandom.current (); int-antal = 0; for (int i = 0; i <5; i ++) {if (isInterested (random.nextInt (10))) {count ++; }} System.out.printf ("Fundet% d interesserede værdier% n", antal); } privat statisk boolsk isInterested (int i) {return i% 2 == 0; }

Antag, at vi er interesserede i at logge faktisk er interesseret opkaldets parametre.

Lad os oprette et ikke-blokerende brudpunkt i målmetoden (Flytte + venstreklik på venstre editor-tagrender). Lad os derefter åbne dens egenskaber (højreklik på brydepunktet) og definer det måludtryk, der skal logges:

Når du kører applikationen (bemærk, at det stadig er nødvendigt at bruge fejlretningstilstand), ser vi output:

isInterested (1) isInterested (4) isInterested (3) isInterested (1) isInterested (6) Fundet 2 interesserede værdier

6. Betingede brudpunkter

Vi kan have en situation, hvor en bestemt metode kaldes fra flere tråde samtidigt, og vi er nødt til at debugge behandlingen bare for et bestemt argument.

IntelliJ tillader det oprettelse af breakpoints, der kun stopper udførelsen, hvis en brugerdefineret betingelse er opfyldt.

Her er et eksempel, der bruger kildekoden ovenfor:

Nu stopper debuggeren kun ved brudpunktet, hvis det givne argument er større end 3.

7. Objektmærker

Dette er den mest kraftfulde og mindst kendte IntelliJ-funktion. Det er ret simpelt i det væsentlige - vi kan vedhæfte brugerdefinerede etiketter til JVM-objekter.

Lad os se på et program, som vi bruger til at demonstrere dem:

public class Test {public static void main (String [] args) {Collection Tasks = Arrays.asList (new Task (), new Task ()); opgaver.forEach (opgave -> ny tråd (opgave) .start ()); } privat statisk ugyldighed mayBeAdd (Collection holder) {int i = ThreadLocalRandom.current (). nextInt (10); hvis (i% 3 == 0) {holder.add (i); }} privat statisk klasse Opgaveimplementeringer Runnable {private final Collection holder = new ArrayList (); @Override public void run () {for (int i = 0; i <20; i ++) {mayBeAdd (holder); }}}}

7.1. Oprettelse af mærker

Et objekt kan markeres, når en applikation stoppes på et brudpunkt, og målet kan nås fra stabelrammer.

Vælg det, tryk på F11 (Marker objekt handling) og definer målnavn:

7.2. Vis mærker

Nu kan vi se vores brugerdefinerede objektetiketter selv i andre dele af applikationen:

Den seje ting er det selvom et markeret objekt ikke kan nås fra stabelrammer i øjeblikket, kan vi stadig se dets tilstand - åbn en Evaluer ekspression dialog, eller tilføj et nyt ur, og begynd at skrive mærkeets navn.

IntelliJ tilbyder at fuldføre det med _DebugLabel suffiks:

Når vi vurderer det, vises målobjektets tilstand:

7.3. Markerer som betingelser

Det er også muligt at bruge mærker i brudpunktforhold:

8. Konklusion

Vi kontrollerede en række teknikker, der øger produktiviteten meget, mens vi fejler en applikation med flere tråde.

Dette er normalt en udfordrende opgave, og vi kan ikke undervurdere vigtigheden af ​​værktøjets hjælp her.