Ein Vorteil der Verwendung von Java besteht darin, dass Sie die Speicherzuweisung und -freigabe nicht selbst verwalten müssen. Wenn Sie ein Objekt mit dem Schlüsselwort new instanziieren, wird der benötigte Speicher automatisch im Java-Heap zugewiesen. Der Heap wird vom Garbage Collector verwaltet und beansprucht Speicher zurück, wenn Objekte den Gültigkeitsbereich verlassen. Es gibt jedoch eine „Hintertür“ in der JVM, die Ihnen den Zugriff auf nativen Speicher ermöglicht, der sich nicht im Heap befindet. In diesem Artikel zeige ich Ihnen, wie ein Objekt als kontinuierlicher Bytecode im Speicher gespeichert wird, und erkläre Ihnen, wie diese Bytes gespeichert werden sollten, sei es im Java-Heap oder im lokalen Speicher. Abschließend werde ich einige Schlussfolgerungen dazu ziehen, wie man schneller auf den Speicher der JVM zugreifen kann: mithilfe des Java-Heaps oder des lokalen Speichers.
Unsafe, um Speicher zuzuweisen und freizugeben. sun.misc.Unsafe ermöglicht Ihnen das Zuweisen und Freigeben von lokalem Speicher in Java, genau wie malloc und free in der C-Sprache. Der dadurch zugewiesene Speicher befindet sich nicht im Java-Heap und wird nicht vom Garbage Collector verwaltet. Sie müssen also dafür verantwortlich sein, ihn selbst freizugeben und zu recyceln, wenn er aufgebraucht ist. Das Folgende ist eine von mir geschriebene Toolklasse, die Unsafe zum Verwalten des lokalen Speichers verwendet:
public class Direct implements Memory {
private static Unsafe unsafe;
private static boolean AVAILABLE = false;
static {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
unsafe = (Unsafe)field.get(null);
AVAILABLE = true;
} catch(Exception e) {
// NOOP: throw exception later when allocating memory
}
}
public static boolean isAvailable() {
return AVAILABLE;
}
private static Direct INSTANCE = null;
public static Memory getInstance() {
if (INSTANCE == null) {
INSTANCE = new Direct();
}
return INSTANCE;
}
private Direct() {
}
@Override
public long alloc(long size) {
if (!AVAILABLE) {
throw new IllegalStateException("sun.misc.Unsafe is not accessible!");
}
return unsafe.allocateMemory(size);
}
@Override
public void free(long address) {
unsafe.freeMemory(address);
}
@Override
public final long getLong(long address) {
return unsafe.getLong(address);
}
@Override
public final void putLong(long address, long value) {
unsafe.putLong(address, value);
}
@Override
public final int getInt(long address) {
return unsafe.getInt(address);
}
@Override
public final void putInt(long address, int value) {
unsafe.putInt(address, value);
}
}Lassen Sie uns das folgende Java-Objekt in den lokalen Speicher legen:
public class SomeObject {
private long someLong;
private int someInt;
public long getSomeLong() {
return someLong;
}
public void setSomeLong(long someLong) {
this.someLong = someLong;
}
public int getSomeInt() {
return someInt;
}
public void setSomeInt(int someInt) {
this.someInt = someInt;
}
}Alles, was wir getan haben, war, die Attribute des Objekts in Memory einzufügen:
public class SomeMemoryObject {
private final static int someLong_OFFSET = 0;
private final static int someInt_OFFSET = 8;
private final static int SIZE = 8 + 4; // one long + one int
private long address;
private final Memory memory;
public SomeMemoryObject(Memory memory) {
this.memory = memory;
this.address = memory.alloc(SIZE);
}
@Override
public void finalize() {
memory.free(address);
}
public final void setSomeLong(long someLong) {
memory.putLong(address + someLong_OFFSET, someLong);
}
public final long getSomeLong() {
return memory.getLong(address + someLong_OFFSET);
}
public final void setSomeInt(int someInt) {
memory.putInt(address + someInt_OFFSET, someInt);
}
public final int getSomeInt() {
return memory.getInt(address + someInt_OFFSET);
}
}Jetzt schauen wir uns die Lese- und Schreibleistung von zwei <🎜 an >Arrays: eines enthält Millionen von -Objekten und das andere enthält Millionen von SomeObject-Objekten. SomeMemoryObject
// with JIT: Number of Objects: 1,000 1,000,000 10,000,000 60,000,000 Heap Avg Write: 107 2.30 2.51 2.58 Native Avg Write: 305 6.65 5.94 5.26 Heap Avg Read: 61 0.31 0.28 0.28 Native Avg Read: 309 3.50 2.96 2.16 // without JIT: (-Xint) Number of Objects: 1,000 1,000,000 10,000,000 60,000,000 Heap Avg Write: 104 107 105 102 Native Avg Write: 292 293 300 297 Heap Avg Read: 59 63 60 58 Native Avg Read: 297 298 302 299
Fazit: Das Lesen des lokalen Speichers über die JVM-Barriere hinweg ist etwa zehnmal langsamer als das direkte Lesen des Speichers im Java-Heap, und Schreibvorgänge sind etwa zweimal langsamer. Es ist jedoch zu beachten, dass die Lese- und Schreibvorgänge nicht kontinuierlich sind, da der von jedem SomeMemoryObject-Objekt verwaltete lokale Speicherplatz unabhängig ist. Vergleichen wir dann die Leistung beim Lesen und Schreiben von kontinuierlichem Speicherplatz.
Zugriff auf einen großen zusammenhängenden SpeicherbereichDieser Test enthält die gleichen Testdaten im Heap und in einem großen zusammenhängenden lokalen Speicher. Dann führen wir mehrere Lese- und Schreibvorgänge durch, um zu sehen, welcher schneller ist. Und wir werden einen zufälligen Adresszugriff durchführen, um die Ergebnisse zu vergleichen.// with JIT and sequential access: Number of Objects: 1,000 1,000,000 1,000,000,000 Heap Avg Write: 12 0.34 0.35 Native Avg Write: 102 0.71 0.69 Heap Avg Read: 12 0.29 0.28 Native Avg Read: 110 0.32 0.32 // without JIT and sequential access: (-Xint) Number of Objects: 1,000 1,000,000 10,000,000 Heap Avg Write: 8 8 8 Native Avg Write: 91 92 94 Heap Avg Read: 10 10 10 Native Avg Read: 91 90 94 // with JIT and random access: Number of Objects: 1,000 1,000,000 1,000,000,000 Heap Avg Write: 61 1.01 1.12 Native Avg Write: 151 0.89 0.90 Heap Avg Read: 59 0.89 0.92 Native Avg Read: 156 0.78 0.84 // without JIT and random access: (-Xint) Number of Objects: 1,000 1,000,000 10,000,000 Heap Avg Write: 55 55 55 Native Avg Write: 141 142 140 Heap Avg Read: 55 55 55 Native Avg Read: 138 140 138
Schlussfolgerung:Beim kontinuierlichen Zugriff ist der Java-Heapspeicher normalerweise schneller als der lokale Speicher. Für den wahlfreien Zugriff auf Adressen ist der Heap-Speicher nur geringfügig langsamer als der lokale Speicher, und wenn es um große Blöcke zusammenhängender Daten geht, ist er nicht viel langsamer.
Abschließendes FazitDie Verwendung des lokalen Speichers in Java hat seine Bedeutung, beispielsweise wenn Sie mit großen Datenmengen (>2G) arbeiten und den Garbage Collector nicht verwenden möchten ( GC) Zeit. Aus Sicht der Latenz ist der direkte Zugriff auf den lokalen Speicher nicht schneller als der Zugriff auf den Java-Heap. Diese Schlussfolgerung ist tatsächlich sinnvoll, da das Überwinden der JVM-Barriere definitiv mit einem Mehraufwand verbunden ist. Diese Schlussfolgerung gilt auch für die Verwendung von Local oder Heap. Die Geschwindigkeitsverbesserung bei der Verwendung von lokalem ByteBuffer besteht nicht darin, auf diese Speicher zuzugreifen, sondern darin, dass es direkt mit dem vom Betriebssystem bereitgestellten lokalen E/A arbeiten kann ByteBuffer
Das obige ist der detaillierte Inhalt vonWas ist schneller: Java-Heap oder lokaler Speicher?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
