Verschil tussen JVM, JRE en JDK

1. Overzicht

In dit artikel bespreken we de verschillen tussen JVM, JRE en JDK door hun componenten en toepassingen in overweging te nemen.

2. JVM

Java Virtual Machine (JVM) is een implementatie van een virtuele machine die een Java-programma uitvoert.

De JVM interpreteert eerst de bytecode. Het slaat vervolgens de klasse-informatie op in het geheugengebied. Ten slotte voert het de bytecode uit die door de java-compiler is gegenereerd.

Het is een abstracte rekenmachine met een eigen instructieset en manipuleert verschillende geheugengebieden tijdens runtime.

Onderdelen van de JVM zijn:

  • Klasse laders
  • Runtime-gegevensgebieden
  • Uitvoeringsmotor

2.1. Klasse laders

De eerste taken van de JVM omvatten het laden, verifiëren en koppelen van de bytecode. Klasseladers kunnen deze taken uitvoeren.

We hebben een gedetailleerd artikel specifiek over klasse-laders.

2.2. Runtime-gegevensgebieden

De JVM definieert verschillende geheugengebieden om een ​​Java-programma uit te voeren. Deze worden tijdens runtime gebruikt en staan ​​bekend als runtime-gegevensgebieden. Sommige van deze gebieden worden gemaakt bij het opstarten van JVM en vernietigd wanneer de JVM wordt afgesloten, terwijl andere worden gemaakt wanneer een thread wordt gemaakt en vernietigd wanneer een thread wordt afgesloten.

Laten we deze gebieden een voor een bekijken:

Methode gebied

In wezen is het methodegebied analoog aan het opslaggebied voor gecompileerde code. Het slaat structuren op zoals run-time constant pool, veld- en methode-gegevens, de code voor methoden en constructeurs, evenals volledig gekwalificeerde klassenamen. De JVM slaat deze structuur voor elke klas op.

Het methodegebied, ook wel permanente generatieruimte (PermGen) genoemd, wordt gemaakt wanneer de JVM opstart. Het geheugen voor dit gebied hoeft niet aaneengesloten te zijn. Alle JVM-threads delen dit geheugengebied.

Heap-gebied

De JVM wijst het geheugen toe aan alle klasse-instanties en arrays uit dit gebied.

Garbage Collector (GC) haalt het heap-geheugen terug voor objecten. In principe heeft GC drie fasen om geheugen terug te winnen van objecten, namelijk. twee kleine GC en één grote GC.

Het heap-geheugen heeft drie delen:

  • Eden Space - het maakt deel uit van de Young Generation-ruimte. Wanneer we een object maken, wijst de JVM geheugen uit deze ruimte toe
  • Survivor Space - het maakt ook deel uit van de Young Generation-ruimte. Overlevende ruimte bevat bestaande objecten die de kleine GC-fasen van GC hebben overleefd
  • Tenured Space - dit wordt ook wel de Old Generation-ruimte genoemd. Het bevat lang overgebleven objecten. In principe wordt er een drempel ingesteld voor Young Generation-objecten en wanneer deze drempel wordt bereikt, worden deze objecten verplaatst naar een vaste ruimte.

JVM maakt een heap-gebied aan zodra het opstart. Alle threads van de JVM delen dit gebied. Het geheugen voor het heapgebied hoeft niet aaneengesloten te zijn.

Stapelgebied

Slaat gegevens op als frames en elk frame slaat lokale variabelen, gedeeltelijke resultaten en geneste methodeaanroepen op. JVM maakt het stapelgebied aan wanneer het een nieuwe thread maakt. Dit gebied is privé voor elke thread.

Elk item in de stapel wordt Stack Frame of Activeringsrecord genoemd. Elk frame bestaat uit drie delen:

  • Local Variable Array - bevat alle lokale variabelen en parameters van de methode
  • Operand Stack - wordt gebruikt als een werkruimte voor het opslaan van het resultaat van tussenliggende berekeningen
  • Framegegevens - worden gebruikt om gedeeltelijke resultaten op te slaan, waarden voor methoden te retourneren en te verwijzen naar de Uitzondering tabel die corresponderende catch block-informatie biedt in het geval van uitzonderingen

Het geheugen voor de JVM-stack hoeft niet aaneengesloten te zijn.

PC-registers

Elke JVM-thread heeft een afzonderlijk pc-register waarin het adres van de momenteel uitgevoerde instructie wordt opgeslagen. Als de instructie die momenteel wordt uitgevoerd een onderdeel is van de oorspronkelijke methode, is deze waarde niet gedefinieerd.

Native methodestapels

Native methoden zijn methoden die zijn geschreven in andere talen dan Java.

JVM biedt mogelijkheden om deze native methoden aan te roepen. Native method-stacks worden ook wel "C-stacks" genoemd. Ze slaan de informatie over de oorspronkelijke methode op. Telkens wanneer de native methoden in machinecodes worden gecompileerd, gebruiken ze meestal een native methodestack om hun status bij te houden.

De JVM maakt deze stapels wanneer hij een nieuwe thread maakt. En dus delen JVM-threads dit gebied niet.

2.3. Uitvoeringsmotor

Uitvoeringsengine voert de instructies uit met behulp van informatie die aanwezig is in de geheugengebieden. Het bestaat uit drie delen:

Tolk

Zodra classloaders bytecode laden en verifiëren, voert de interpreter de bytecode regel voor regel uit. Deze uitvoering is vrij traag. Het nadeel van de tolk is dat wanneer een methode meerdere keren wordt aangeroepen, er telkens een nieuwe interpretatie nodig is.

De JVM gebruikt echter JIT Compiler om dit nadeel te verminderen.

Just-In-Time (JIT) -compiler

JIT-compiler compileert de bytecode van de vaak genoemde methoden tijdens runtime in native code. Daarom is het verantwoordelijk voor de optimalisatie van de Java-programma's.

JVM controleert automatisch welke methoden worden uitgevoerd. Zodra een methode in aanmerking komt voor JIT-compilatie, wordt deze gepland voor compilatie in machinecode. Deze methode staat dan bekend als een hete methode. Deze compilatie naar machinecode gebeurt op een aparte JVM-thread.

Hierdoor wordt de uitvoering van het huidige programma niet onderbroken. Na compilatie in machinecode werkt het sneller.

Vuilnisman

Java zorgt voor het geheugenbeheer met Garbage Collection. Het is een proces van kijken naar heap-geheugen, identificeren welke objecten in gebruik zijn en welke niet, en uiteindelijk ongebruikte objecten verwijderen.

GC is een daemon-thread. Het kan expliciet worden aangeroepen met Systeem.gc() methode, het zal echter niet onmiddellijk worden uitgevoerd en de JVM beslist wanneer GC wordt aangeroepen.

2.4. Native Java-interface

Het fungeert als een interface tussen de Java-code en de native (C / C ++) bibliotheken.

Er zijn situaties waarin Java alleen niet voldoet aan de behoeften van uw applicatie, bijvoorbeeld het implementeren van een platformafhankelijke functie.

In die gevallen kunnen we JNI gebruiken om de code die in de JVM draait te bellen. Omgekeerd maakt het systeemeigen methoden mogelijk om de code aan te roepen die in de JVM wordt uitgevoerd.

2.5. Native bibliotheken

Dit zijn platformspecifieke bibliotheken en bevatten de implementatie van native methoden.

3. JRE

Java Runtime Environment (JRE) is een bundel softwarecomponenten die wordt gebruikt om Java-applicaties uit te voeren.

Kerncomponenten van de JRE zijn onder meer:

  • Een implementatie van een Java Virtual Machine (JVM)
  • Klassen die nodig zijn om de Java-programma's uit te voeren
  • Eigenschappenbestanden

We hebben de JVM in de bovenstaande sectie besproken. Hier zullen we ons concentreren op de kernklassen en ondersteuningsbestanden.

3.1. Bootstrap-lessen

We zullen bootstrap-klassen vinden onder jre / lib /. Dit pad wordt ook wel het bootstrap-klassenpad genoemd. Het bevat:

  • Runtime-klassen in rt.jar
  • Internationaliseringslessen in i18n.jar
  • Tekenconversieklassen in charsets.jar
  • Anderen

Bootstrap ClassLoader laadt deze klassen wanneer de JVM opstart.

3.2. Uitbreidingsklassen

We kunnen uitbreidingsklassen vinden in jre / lib / extn / die fungeert als een directory voor extensies op het Java-platform. Dit pad wordt ook wel extensie classpath genoemd.

Het bevat JavaFX-runtimebibliotheken in jfxrt.jar en locale gegevens voor java.text en java.util pakketten in localedata.jar. Gebruikers kunnen ook aangepaste potten aan deze map toevoegen.

3.3. Eigenschapinstellingen

Het Java-platform gebruikt deze eigenschapsinstellingen om de configuratie te behouden. Afhankelijk van hun gebruik bevinden ze zich in verschillende mappen binnenin / jre / lib /. Waaronder:

  • Kalenderconfiguraties in het calendar.properties
  • Configuraties inloggen logging.properties
  • Netwerkconfiguraties in net.properties
  • Implementatie-eigenschappen in / jre / lib / deploy /
  • Beheer eigenschappen in / jre / lib / beheer /

3.4. Andere bestanden

Afgezien van de bovengenoemde bestanden en klassen, bevat JRE ook bestanden voor andere zaken:

  • Beveiligingsbeheer bij jre / lib / security
  • De map voor het plaatsen van ondersteuningsklassen voor applets op jre / lib / applet
  • Lettertype-gerelateerde bestanden op jre / lib / fonts en anderen

4. JDK

Java Development Kit (JDK) biedt een omgeving en tools voor het ontwikkelen, compileren, debuggen en uitvoeren van een Java-programma.

Kerncomponenten van JDK zijn onder meer:

  • JRE
  • Ontwikkelingshulpmiddelen

We hebben de JRE in de bovenstaande sectie besproken.

Nu zullen we ons concentreren op verschillende ontwikkeltools. Laten we deze tools categoriseren op basis van hun gebruik:

4.1. Basishulpmiddelen

Deze tools vormen de basis van de JDK en worden gebruikt om Java-applicaties te maken en te bouwen. Onder deze tools kunnen we hulpprogramma's vinden voor compileren, debuggen, archiveren, genereren van Javadocs, enz.

Ze bevatten:

  • Javac - leest klasse- en interfacedefinities en compileert ze in klassebestanden
  • Java - start de Java-applicatie
  • javadoc - genereert HTML-pagina's met API-documentatie uit Java-bronbestanden
  • geschikt - vindt en voert annotatieprocessors uit op basis van de annotaties die aanwezig zijn in de set gespecificeerde bronbestanden
  • appletviewer - stelt ons in staat om Java-applets uit te voeren zonder een webbrowser
  • pot - verpakt Java-applets of -toepassingen in één archief
  • jdb - een opdrachtregelprogramma voor foutopsporing dat wordt gebruikt om bugs in Java-toepassingen op te sporen en op te lossen
  • javah - produceert C-header- en bronbestanden van een Java-klasse
  • Javap - demonteert de klassenbestanden en geeft informatie weer over velden, constructors en methoden die aanwezig zijn in een klassenbestand
  • extcheck - detecteert versieconflicten tussen het doel-Java Archive (JAR) -bestand en de momenteel geïnstalleerde extensie JAR-bestanden

4.2. Beveiligingshulpmiddelen

Deze omvatten tools voor sleutel- en certificaatbeheer die worden gebruikt om Java Keystores te manipuleren.

Een Java Keystore is een container voor autorisatiecertificaten of openbare sleutelcertificaten. Daarom wordt het vaak gebruikt door Java-gebaseerde applicaties voor codering, authenticatie en serveren via HTTPS.

Ze helpen ook bij het opstellen van het beveiligingsbeleid op ons systeem en bij het maken van toepassingen die binnen de reikwijdte van dit beleid in de productieomgeving kunnen werken. Waaronder:

  • belangrijk hulpmiddel - helpt bij het beheren van keystore-items, namelijk cryptografische sleutels en certificaten
  • jarsigner - genereert digitaal ondertekende JAR-bestanden met behulp van keystore-informatie
  • beleidstool - stelt ons in staat om de configuratiebestanden van het externe beleid te beheren die het beveiligingsbeleid van de installatie bepalen

Sommige beveiligingshulpmiddelen helpen ook bij het beheren van Kerberos-tickets.

Kerberos is een netwerkverificatieprotocol.

Het werkt op basis van tickets om knooppunten die via een niet-beveiligd netwerk communiceren hun identiteit op een veilige manier aan elkaar te laten bewijzen:

  • kinit - gebruikt om Kerberos-tickets voor het verlenen van tickets te verkrijgen en in de cache te plaatsen
  • ktab - beheert hoofdnamen en sleutelparen in de sleuteltabel
  • klist - geeft vermeldingen weer in de lokale inloggegevenscache en sleuteltabel

4.3. Internationaliseringstool

Internationalisering is het proces waarbij een applicatie zo wordt ontworpen dat deze kan worden aangepast aan verschillende talen en regio's zonder technische wijzigingen.

Voor dit doel brengt de JDK native2ascii. Deze tool converteert een bestand met tekens die door JRE worden ondersteund naar bestanden die zijn gecodeerd in ASCII- of Unicode-escapes.

4.4. Remote Method Invocation (RMI) Tools

RMI-tools maken communicatie op afstand tussen Java-applicaties mogelijk, waardoor er ruimte is voor de ontwikkeling van gedistribueerde applicaties.

Met RMI kan een object dat in de ene JVM wordt uitgevoerd, methoden aanroepen voor een object dat in een andere JVM wordt uitgevoerd. Deze tools zijn onder meer:

  • rmic - genereert stub-, skeleton- en tie-klassen voor objecten op afstand met behulp van het Java Remote Method Protocol (JRMP) of Internet Inter-Orb Protocol (IIOP)
  • registratie - maakt en start het register van externe objecten
  • rmid - sstart de daemon van het activeringssysteem. Hierdoor kunnen objecten worden geregistreerd en geactiveerd in een Java Virtual Machine
  • seriever - geeft seriële versie-UID terug voor gespecificeerde klassen

4.5. Java IDL en RMI-IIOP Tools

Java Interface Definition Language (IDL) voegt CORBA-mogelijkheid (Common Object-Based Request Broker Architecture) toe aan het Java-platform.

Deze tools stellen gedistribueerde Java-webtoepassingen in staat om bewerkingen op externe netwerkservices uit te voeren met behulp van de industriestandaard Object Management Group (OMG) - IDL.

Evenzo zouden we Internet InterORB Protocol (IIOP) kunnen gebruiken.

RMI-IIOP, d.w.z. RMI over IIOP maakt programmering van CORBA-servers en -applicaties mogelijk via de RMI API. Zo is verbinding mogelijk tussen twee applicaties die zijn geschreven in elke CORBA-compatibele taal via Internet InterORB Protocol (IIOP).

Deze tools zijn onder meer:

  • tnameserv - transient Naming Service die een map met boomstructuur voor objectreferenties biedt
  • idlj - de IDL-naar-Java-compiler voor het genereren van de Java-bindingen voor een opgegeven IDL-bestand
  • orbd - stellen clients in staat om op transparante wijze persistente objecten op de server te lokaliseren en aan te roepen in de CORBA-omgeving
  • servertool - biedt een opdrachtregelinterface om een ​​persistente server te registreren of uit te schrijven bij ORB Daemon (orbd), start en sluit een permanente server die is geregistreerd bij ORB Daemon, enzovoort

4.6. Java-implementatiehulpmiddelen

Deze tools helpen bij het implementeren van Java-applicaties en applets op internet. Ze bevatten:

  • pakket200 - transformeert een JAR-bestand in een pakket200 bestand met behulp van de Java gzip compressor
  • uitpakken200 - transformeert pakket200 bestand in een JAR-bestand

4.7. Java Plug-in Tool

JDK biedt ons htmlconverter. Bovendien wordt het gebruikt in combinatie met de Java-plug-in.

Enerzijds brengt Java Plug-in een verbinding tot stand tussen populaire browsers en het Java-platform. Door deze verbinding kunnen applets op de website binnen een browser draaien.

Aan de andere kant, htmlconverter is een hulpprogramma voor het converteren van een HTML-pagina met applets naar een indeling voor Java Plug-in.

4.8. Java Web Start Tool

JDK brengt kaken. We kunnen het gebruiken in combinatie met Java Web Start.

Met deze tool kunnen we Java-applicaties downloaden en starten met een enkele klik vanuit de browser. Daarom is het niet nodig om een ​​installatieproces uit te voeren.

4.9. Monitoring- en beheertools

Dit zijn geweldige tools die we kunnen gebruiken om de JVM-prestaties en het resourceverbruik te bewaken. Hier zijn er een paar:

  • jconsole - biedt een grafische console waarmee u Java-toepassingen kunt volgen en beheren
  • jps - geeft een lijst van de geïnstrumenteerde JVM's op het doelsysteem
  • jstat - bewaakt JVM-statistieken
  • jstatd - bewaakt het maken en beëindigen van geïnstrumenteerde JVM's

4.10. Hulpmiddelen voor probleemoplossing

Dit zijn experimentele tools die we kunnen gebruiken voor het oplossen van problemen:

  • info - genereert configuratie-informatie voor een gespecificeerd Java-proces
  • jmap - drukt geheugenkaarten voor gedeelde objecten of heapgeheugendetails van een gespecificeerd proces af
  • jsadebugd - hecht aan een Java-proces en fungeert als een foutopsporingsserver
  • jstack - drukt Java-stack-sporen van Java-threads af voor een bepaald Java-proces

5. Conclusie

In dit artikel hebben we vastgesteld dat het fundamentele verschil tussen JVM, JRE en JDK ligt in het gebruik ervan.

Eerst hebben we beschreven hoe de JVM een abstracte computer is die de Java-bytecode daadwerkelijk uitvoert.

Vervolgens hebben we uitgelegd hoe we gewoon Java-applicaties kunnen draaien, we gebruiken de JRE.

En tot slot, we begrepen hoe we Java-applicaties moesten ontwikkelen, we gebruiken de JDK.

We hebben ook de tijd genomen om in tools en fundamentele concepten van deze componenten te graven.