streamalism.org

1. Overzicht

In deze tutorial zullen we er enkele bekijken geavanceerde IntelliJ-foutopsporingsfaciliteiten.

Aangenomen wordt dat de basisprincipes van foutopsporing al bekend zijn (hoe u begint met foutopsporing, Stap in, Overstappen acties enz.). Als dit niet het geval is, raadpleeg dan dit artikel voor meer informatie hierover.

2. Slimme stap in

Er zijn situaties waarin meerdere methoden worden aangeroepen op een enkele regel broncode, zoals doJob (getArg1 (), getArg2 ()). Als we bellen Stap in action (F7), gaat de debugger naar de methoden in de volgorde die door de JVM wordt gebruikt voor evaluatie: getArg1 – getArg2 – doeJob.

Echter, we willen misschien alle tussenliggende aanroepen overslaan en direct doorgaan naar de doelmethode. Slimme stap in actie maakt dat mogelijk.

Haar gebonden aan de Shift + F7 standaard en ziet er zo uit wanneer aangeroepen:

Nu kunnen we de doelmethode kiezen om verder te gaan. Merk ook op dat IntelliJ altijd de buitenste methode bovenaan de lijst plaatst. Dat betekent dat we er snel naartoe kunnen door op te drukken Shift + F7 | Enter.

3. Frame laten vallen

We realiseren ons misschien dat sommige bewerkingen waarin we geïnteresseerd zijn al hebben plaatsgevonden (bijvoorbeeld de berekening van het huidige methode-argument). In dit geval, het is mogelijk om de huidige JVM-stackframe (s) te verwijderen om ze opnieuw te verwerken.

Overweeg de volgende situatie:

Stel dat we geïnteresseerd zijn in foutopsporing getArg1 verwerking, dus laten we het huidige frame (doeJob methode):

Nu we zitten in de vorige methode:

De oproepargumenten zijn op dit punt echter al berekend, dus we moeten ook het huidige frame verwijderen:

Nu kunnen we de verwerking opnieuw uitvoeren door te bellen Stap in.

4. Veldbreekpunten

Soms worden niet-privévelden gewijzigd door andere klassen, niet via setters maar rechtstreeks (dat is het geval bij bibliotheken van derden waar we geen controle hebben over de broncode).

In dergelijke situaties is het misschien moeilijk te begrijpen wanneer de wijziging is doorgevoerd. Met IntelliJ kunt u onderbrekingspunten op veldniveau maken om dat bij te houden.

Ze zijn zoals gewoonlijk ingesteld - klik met de linkermuisknop op de linker editor-rugmarge op de veldregel. Daarna is het mogelijk om open breekpunteigenschappen (klik met de rechtermuisknop op het breekpuntmarkering) en configureer of we geïnteresseerd zijn in het lezen, schrijven of beide van het veld:

5. Logboekregistratie van breekpunten

Soms weten we dat er een raceconditie in de applicatie zit, maar weten we niet waar deze precies is. Het kan een uitdaging zijn om het vast te stellen, vooral als u met nieuwe code werkt.

We kunnen foutopsporingsverklaringen toevoegen aan de bronnen van ons programma. Deze mogelijkheid bestaat echter niet voor bibliotheken van derden.

De IDE kan hierbij helpen - het maakt het mogelijk onderbrekingspunten in te stellen die de uitvoering van een eenmaal treffer niet blokkeren, maar in plaats daarvan logboekinstructies produceren.

Beschouw het volgende voorbeeld:

openbare statische leegte hoofd (String [] args) {ThreadLocalRandom random = ThreadLocalRandom.current (); int count = 0; voor (int i = 0; i <5; i ++) {if (isInterested (random.nextInt (10))) {count ++; }} System.out.printf ("% d geïnteresseerde waarden% n gevonden", aantal); } privé statische boolean isInterested (int i) {return i% 2 == 0; }

Stel dat we geïnteresseerd zijn in het daadwerkelijk loggen is geintereseerd oproep parameters.

Laten we een niet-blokkerend breekpunt maken in de doelmethode (Verschuiving + linkermuisknop op de linker editor-rugmarge). Laten we daarna de eigenschappen openen (klik met de rechtermuisknop op het breekpunt) en definieer de doelexpressie die moet worden geregistreerd:

Bij het uitvoeren van de applicatie (merk op dat het nog steeds nodig is om de foutopsporingsmodus te gebruiken), zullen we de uitvoer zien:

isInterested (1) isInterested (4) isInterested (3) isInterested (1) isInterested (6) 2 geïnteresseerde waarden gevonden

6. Voorwaardelijke breekpunten

We kunnen een situatie hebben waarin een bepaalde methode wordt aangeroepen vanuit meerdere threads tegelijk en we de verwerking alleen voor een bepaald argument moeten debuggen.

IntelliJ staat toe het maken van onderbrekingspunten die de uitvoering alleen pauzeren als aan een door de gebruiker gedefinieerde voorwaarde is voldaan.

Hier is een voorbeeld dat de bovenstaande broncode gebruikt:

Nu stopt de debugger alleen op het breekpunt als het opgegeven argument groter is dan 3.

7. Objectmarkeringen

Dit is de krachtigste en minst bekende IntelliJ-functie. Het is in wezen vrij eenvoudig - we kunnen aangepaste labels aan JVM-objecten bevestigen.

Laten we eens kijken naar een applicatie die we zullen gebruiken om ze te demonstreren:

openbare klasse Test {openbare statische leegte hoofd (String [] args) {Verzameling taken = Arrays.asList (nieuwe taak (), nieuwe taak ()); taken.forEach (taak -> nieuwe thread (taak) .start ()); } privé statische leegte mayBeAdd (collectiehouder) {int i = ThreadLocalRandom.current (). nextInt (10); if (i% 3 == 0) {holder.add (i); }} private statische klasse Taak implementeert Runnable {private final Collection holder = new ArrayList (); @Override public void run () {for (int i = 0; i <20; i ++) {mayBeAdd (houder); }}}}

7.1. Markeringen maken

Een object kan worden gemarkeerd wanneer een toepassing op een breekpunt wordt gestopt en het doel bereikbaar is vanuit stapelframes.

Selecteer het, druk op F11 (Markeer Object actie) en definieer de naam van het doel:

7.2. Bekijk Marks

Nu kunnen we onze aangepaste objectlabels zelfs in andere delen van de applicatie zien:

Het coole is dat zelfs als een gemarkeerd object op dit moment niet bereikbaar is vanaf stapelframes, kunnen we nog steeds de staat ervan zien - open een Evalueer expressie dialoogvenster of voeg een nieuw horloge toe en begin de naam van het merk te typen.

IntelliJ biedt aan om het te voltooien met de _DebugLabel achtervoegsel:

Wanneer we het evalueren, wordt de staat van het doelobject weergegeven:

7.3. Markeert als voorwaarden

Het is ook mogelijk om markeringen te gebruiken in breekpuntvoorwaarden:

8. Conclusie

We hebben een aantal technieken gecontroleerd die de productiviteit aanzienlijk verhogen tijdens het debuggen van een multi-threaded applicatie.

Dit is meestal een uitdagende taak en we kunnen het belang van de hulp van tooling hier niet onderschatten.