IntelliJ feilsøkingstriks

1. Oversikt

I denne opplæringen vil vi se på noen avanserte IntelliJ feilsøkingsanlegg.

Det antas at grunnleggende om feilsøking allerede er kjent (hvordan du starter feilsøking, Gå inn i, Tråkke over handlinger osv.). Hvis ikke, kan du se denne artikkelen for mer informasjon om det.

2. Smart Step In

Det er situasjoner når flere metoder kalles på en enkelt kildekodelinje, for eksempel doJob (getArg1 (), getArg2 ()). Hvis vi ringer Gå inn i handling (F7), feilsøkingsprogrammet går inn i metodene i rekkefølgen som brukes av JVM for evaluering: getArg1getArg2doJob.

Derimot, kan det være lurt å hoppe over alle mellominnkallinger og fortsette til målmetoden direkte. Smart Step Into handling tillater å gjøre det.

Det er bundet til Skift + F7 som standard og ser slik ut når den påberopes:

Nå kan vi velge målmetoden for å fortsette. Vær også oppmerksom på at IntelliJ alltid setter den ytterste metoden øverst på listen. Det betyr at vi raskt kan gå til det ved å trykke Skift + F7 | Tast inn.

3. Slipp ramme

Vi kan innse at noe behandling vi er interessert i allerede har skjedd (f.eks. Beregning av nåværende metodeargument). I dette tilfellet, det er mulig å slippe gjeldende JVM-stabelramme (r) for å behandle dem på nytt.

Tenk på følgende situasjon:

Anta at vi er interessert i feilsøking getArg1 prosessering, så vi slipper den nåværende rammen (doJob metode):

vi er i den forrige metoden:

Imidlertid er samtaleargumentene allerede beregnet på dette punktet, så, vi må slippe den nåværende rammen også:

Nå kan vi kjøre behandlingen på nytt ved å ringe Gå inn i.

4. Feltbrekkpunkter

Noen ganger endres ikke-private felt av andre klasser, ikke gjennom settere, men direkte (det er tilfellet med tredjepartsbiblioteker der vi ikke kontrollerer kildekoden).

I slike situasjoner kan det være vanskelig å forstå når endringen er gjort. IntelliJ gjør det mulig å opprette bruddpunkter på feltnivå for å spore det.

De er satt som vanlig - venstreklikk på venstre redaktørrenne på feltlinjen. Etter det er det mulig å åpne brytepunktegenskaper (høyreklikk på brytpunktmerket) og konfigurer om vi er interessert i feltets lesing, skriving eller begge deler:

5. Logging av brytepunkter

Noen ganger vet vi at det er et løpstilstand i applikasjonen, men vet ikke hvor det er. Det kan være en utfordring å spikre den, spesielt når du arbeider med ny kode.

Vi kan legge til feilsøkingsuttalelser til programmets kilder. Imidlertid er det ingen slik mulighet for tredjepartsbiblioteker.

IDE kan hjelpe her - det tillater innstilling av brytepunkter som ikke blokkerer utførelse når de treffes, men produserer loggsetninger i stedet.

Tenk på følgende eksempel:

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

Anta at vi er interessert i å logge faktisk erInteressert samtalens parametere.

La oss opprette et ikke-blokkerende brytpunkt i målmetoden (Skifte + venstre-klikk på venstre redaktørrenne). Etter det, la oss åpne egenskapene (høyreklikk på brytpunktet) og definere måluttrykket som skal logges:

Når du kjører applikasjonen (merk at det fortsatt er nødvendig å bruke feilsøkingsmodus), ser vi utdataene:

isInterested (1) isInterested (4) isInterested (3) isInterested (1) isInterested (6) Fant 2 interesserte verdier

6. Betingede bruddpunkter

Vi kan ha en situasjon der en bestemt metode kalles fra flere tråder samtidig, og vi må feilsøke behandlingen bare for et bestemt argument.

IntelliJ tillater opprette bruddpunkter som bare stopper utførelsen hvis en brukerdefinert tilstand er oppfylt.

Her er et eksempel som bruker kildekoden ovenfor:

Nå stopper feilsøkingsprogrammet bare ved bruddpunktet hvis det gitte argumentet er større enn 3.

7. Objektmerker

Dette er den kraftigste og minst kjente IntelliJ-funksjonen. Det er ganske enkelt i det vesentlige - vi kan feste egendefinerte etiketter til JVM-objekter.

La oss ta en titt på et program som vi vil bruke til å demonstrere dem:

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

7.1. Opprette merker

Et objekt kan merkes når en applikasjon stoppes på et brytpunkt og målet nås fra stabelrammer.

Velg den, trykk F11 (Merk objekt handling) og definer målnavn:

7.2. Vis merker

Nå kan vi se våre tilpassede objektetiketter selv i andre deler av applikasjonen:

Det kule er at selv om et merket objekt ikke nås fra stabelrammer for øyeblikket, kan vi fremdeles se dets tilstand - åpne en Evaluer uttrykk dialogboksen eller legg til en ny klokke og begynn å skrive merkets navn.

IntelliJ tilbyr å fullføre den med _DebugLabel suffiks:

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

7.3. Merker som betingelser

Det er også mulig å bruke merker under brytpunktforhold:

8. Konklusjon

Vi sjekket en rekke teknikker som øker produktiviteten mye mens vi feilsøker et program med flere tråder.

Dette er vanligvis en utfordrende oppgave, og vi kan ikke undervurdere viktigheten av verktøyets hjelp her.


$config[zx-auto] not found$config[zx-overlay] not found