Heim  >  Artikel  >  Java  >  Was ist schneller: Java-Heap oder lokaler Speicher?

Was ist schneller: Java-Heap oder lokaler Speicher?

黄舟
黄舟Original
2017-03-20 10:53:321478Durchsuche

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.

Verwenden Sie 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);
    }
}

Ein Objekt im lokalen Speicher zuweisen

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 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 Speicherbereich

Dieser 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 Fazit

Die 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!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn