Qu'est-ce qui est le plus rapide, le tas Java ou la mémoire locale ?

L’un des avantages de l’utilisation de Java est que vous n’avez pas à gérer l’allocation de mémoire ni à vous libérer. Lorsque vous instanciez un objet à l'aide du mot-clé new, la mémoire dont il a besoin est automatiquement allouée dans le tas Java. Le tas est géré par le garbage collector et il récupère de la mémoire lorsque les objets sortent de la portée. Mais il existe une « porte dérobée » dans la JVM qui vous permet d'accéder à la mémoire native qui n'est pas dans le tas. Dans cet article, je vais vous montrer comment un objet est stocké en mémoire sous forme de bytecode continu, et vous expliquer comment ces octets doivent être stockés, que ce soit dans le tas Java ou dans la mémoire locale. Enfin, je donnerai quelques conclusions sur la façon d'accéder plus rapidement à la mémoire depuis la JVM : en utilisant le tas Java ou la mémoire locale.

Utiliser Unsafe pour allouer et désallouer de la mémoire

sun.misc.Unsafe permet d'allouer et de désallouer de la mémoire locale en Java, tout comme malloc et free en langage C. La mémoire allouée via celle-ci ne se trouve pas dans le tas Java et n'est pas gérée par le ramasse-miettes, vous devez donc être responsable de sa libération et de son recyclage vous-même lorsqu'elle est épuisée. Ce qui suit est une classe d'outils que j'ai écrite et qui utilise Unsafe pour gérer la mémoire locale :

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

Allouer un objet dans la mémoire locale

Mettons l'objet Java suivant dans la mémoire locale :

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;
    }
}

Tout ce que nous avons fait a été de mettre les attributs de l'objet dans Memory :

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

Maintenant, nous le faisons. Examinons les performances de lecture et d'écriture de deux tableaux : l'un contenant des millions de SomeObject objets, et l'autre contenant des millions de SomeMemoryObject objets.

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

Conclusion : La lecture de la mémoire locale à travers la barrière JVM est environ 10 fois plus lente que la lecture directe de la mémoire dans le tas Java, et les opérations d'écriture sont environ 2 fois plus lentes. Il convient cependant de noter que l'espace mémoire local géré par chaque objet SomeMemoryObject étant indépendant, les opérations de lecture et d'écriture ne sont pas continues. Comparons ensuite les performances de lecture et d'écriture de l'espace mémoire continu.

Accès à un grand espace mémoire contigu

Ce test contient les mêmes données de test dans le tas et dans une grande mémoire locale contiguë. Ensuite, nous effectuons plusieurs opérations de lecture et d’écriture pour voir laquelle est la plus rapide. Et nous effectuerons un accès aléatoire aux adresses pour comparer les résultats.

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

Conclusion :Lors d'un accès continu, la mémoire tas Java est généralement plus rapide que la mémoire locale. Pour l'accès aux adresses aléatoires, la mémoire tas n'est que légèrement plus lente que la mémoire locale, et lorsqu'elle cible de gros blocs de données contiguës, elle n'est pas beaucoup plus lente.

Conclusion finale

Utiliser la mémoire locale en Java a son sens, par exemple lorsque l'on souhaite opérer sur de gros morceaux de données (>2G) et que l'on ne souhaite pas utiliser le garbage collector ( GC) heure. Du point de vue de la latence, l'accès direct à la mémoire locale n'est pas plus rapide que l'accès au tas Java. Cette conclusion est en fait logique, car il y a certainement une surcharge à franchir la barrière JVM. Cette conclusion s'applique également à l'utilisation de local ou de tas ByteBuffer. L'amélioration de la vitesse d'utilisation du ByteBuffer local ne réside pas dans l'accès à ces mémoires, mais dans le fait qu'il peut fonctionner directement avec les E/S locales fournies par le système d'exploitation

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!