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.
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);
}
}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.
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.
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
