Bottlenecks identificeren
Eerst meten, dan optimaliseren
Bottlenecks identificeren is een gratis Java Academy-les op CoddyKit. Dit is les 1 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Java Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Java Academy bevat in totaal 4 lessen.
Meten, niet gokken
De eerste regel bij prestatieverbetering: meet voordat je optimaliseert.
Intuïtie over waar een Java-programma zijn tijd besteedt, is meestal verkeerd. De JIT-compiler, garbagecollector en caching maken giswerk allemaal onbetrouwbaar. Profileer, vind het echte knelpunt en los dat op.
Een knelpunt gedefinieerd
Een knelpunt is het deel van een systeem dat de totale verwerkingscapaciteit of latentie beperkt.
Optimaliseren van iets anders levert geen zichtbaar voordeel op. De wet van Amdahl maakt dit precies: als 90% van de tijd in één methode zit, kan het versnellen van de overige 10% nooit meer dan 11% verbetering opleveren.
Latentie versus verwerkingscapaciteit
Bepaal wat je optimaliseert:
- Latentie — hoe lang één verzoek duurt.
- Verwerkingscapaciteit — hoeveel verzoeken er per seconde worden verwerkt.
Ze gaan ten koste van elkaar. Werken in batches verhoogt de verwerkingscapaciteit, maar kan de latentie per verzoek verhogen. Ken je doel voordat je gaat afstemmen.
Wandkloktijd meten
De eenvoudigste meting is de wandkloktijd rond een codeblok meten met System.nanoTime().
Dit is nuttig als snelle controle, maar de meting omvat JIT-opwarming, GC-pauzes en ruis door planning van het besturingssysteem. Wees dus wantrouwig tegenover losse getallen.
public class Main {
public static void main(String[] args) {
long start = System.nanoTime();
long sum = 0;
for (int i = 0; i < 10_000_000; i++) sum += i;
long elapsed = System.nanoTime() - start;
System.out.println("Sum: " + sum);
System.out.println("Elapsed ms: " + (elapsed / 1_000_000.0));
}
}Pas op voor JIT-opwarming
Java begint met het interpreteren van bytecode en de JIT compileert daarna vaak uitgevoerde methoden naar machinecode.
De eerste uitvoeringen van een methode zijn daardoor veel trager dan latere uitvoeringen. Een eenvoudige timinglus meet vooral de opwarmfase. Echte prestatiemetingen warmen eerst op en meten daarna de stabiele toestand — precies wat JMH voor je doet.
CPU-gebonden versus I/O-gebonden
Bepaal welk soort knelpunt het is:
- CPU-gebonden — threads zijn druk aan het rekenen; processorkernen zijn volledig belast.
- I/O-gebonden — threads wachten op schijf, netwerk of database.
Profileringsprogramma's onderscheiden dit als tijd 'op de CPU' versus 'geblokkeerde/wachtende' tijd. De oplossing verschilt volledig: snellere algoritmen versus meer gelijktijdigheid of minder heen-en-terugcommunicatie.
Steekproeven versus instrumentatie
Twee strategieën voor profilering:
- Steekproeven — leg periodiek aanroepstacks vast. Lage extra belasting, statistisch.
- Instrumentatie — voeg tellers toe aan elke methode. Exact, maar zwaar en het kan de metingen vertekenen.
Geef in productie de voorkeur aan profilering met weinig extra belasting, zoals Java Flight Recorder.
Geheugen als knelpunt
Vaak zijn geheugentoewijzingen de echte kostenpost, niet de berekening. Het voortdurend aanmaken van objecten activeert vaak garbagecollection, wat CPU-capaciteit wegneemt en pauzes toevoegt.
Let op de toewijzingssnelheid en GC-tijd. Het verminderen van toewijzingen in een intensief uitgevoerde lus levert vaak meer op dan micro-optimalisatie van rekenwerk.
import java.util.ArrayList;
import java.util.List;
public class Main {
public static void main(String[] args) {
// Allocation-heavy: a new String each iteration
List<String> garbage = new ArrayList<>();
for (int i = 0; i < 5; i++) {
garbage.add("item-" + i);
}
System.out.println("Allocated " + garbage.size() + " strings");
System.out.println("In a hot loop, this churn drives GC pressure");
}
}Bovenaan de aanroepstack vinden
Een profiler op basis van steekproeven produceert een lijst met methoden, gerangschikt naar hoe vaak ze in een CPU-aanroepstack voorkwamen — de eigen tijd.
De methode bovenaan is je kandidaat. Bevestig wel dat die zich op het kritieke pad bevindt: een intensief gebruikte methode in een logger die op de achtergrond draait, heeft misschien geen invloed op de latentie die de gebruiker ervaart.
Een referentiemeting vastleggen
Leg voordat je iets verandert een referentiemeting vast onder realistische belasting.
Meet na elke wijziging opnieuw en vergelijk. Zonder een referentiemeting kun je niet bewijzen dat een optimalisatie heeft geholpen — en veel 'optimalisaties' maken de situatie erger. Wijzig één ding tegelijk.
Profileren onder realistische belasting
Een knelpunt dat op een inactieve laptop wordt gevonden, is misschien niet het knelpunt dat in productie problemen veroorzaakt.
- Gebruik representatieve gegevensgroottes en gelijktijdigheid.
- Reproduceer de werklast die er voor gebruikers echt toe doet.
Synthetische microtests kunnen je wijzen op een methode die op schaal irrelevant is. Profileer waar het probleem zich echt voordoet.
Korte controle
Waarom zijn losse, naïeve metingen van een Java-methode met System.nanoTime() vaak misleidend?
Samenvatting
Knelpunten op de gedisciplineerde manier vinden:
- Meet voordat je optimaliseert; intuïtie liegt.
- Kies een doel: latentie of doorvoer.
- Bepaal of de belasting CPU- of IO-gebonden is; let op GC en allocatie.
- Geef de voorkeur aan profilering op basis van steekproeven met lage overhead.
- Pas op voor het opwarmen van de JIT; stel een referentiemeting vast en verander één ding tegelijk.
Leer Java met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 104
- Lessen
- 374
Veelgestelde vragen
Is de les “Bottlenecks identificeren” gratis?
Ja — de volledige tekst van “Bottlenecks identificeren” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Java Academy wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Java Academy bevat in totaal 4 lessen.
Wat leer ik in “Bottlenecks identificeren”?
Eerst meten, dan optimaliseren Je oefent met Java Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Java Academy te beginnen?
Ervaring vooraf is niet nodig. Java Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 1 van 4.
Hoe lang duurt de les “Bottlenecks identificeren”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Java Academy?
Ja. Elke les over Java Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Bottlenecks identificeren
- Java Flight Recorder
- Analyseren met JDK Mission Control
- Veelgebruikte JVM-tuningflags