La Mémoire partagée entre deux machines virtuelles

Solution 1:

La meilleure solution à mon avis est d'utiliser les fichiers mappés en mémoire. Cela vous permet de partager une région de la mémoire entre un nombre quelconque de processus, y compris d'autres non des programmes java. Vous ne pouvez pas placer des objets java dans un fichier mappé en mémoire, à moins que vous sérialiser eux. L'exemple suivant montre que vous pouvez établir la communication entre deux processus différents, mais vous devez le rendre beaucoup plus sophistiqués pour permettre une meilleure communication entre les processus. Je vous suggère de regarder à Java NIO paquet, plus précisément les classes et les méthodes utilisées dans les exemples ci-dessous.

Serveur:

public class Server {

    public static void main( String[] args ) throws Throwable {
        File f = new File( FILE_NAME );

        FileChannel channel = FileChannel.open( f.toPath(), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE );

        MappedByteBuffer b = channel.map( MapMode.READ_WRITE, 0, 4096 );
        CharBuffer charBuf = b.asCharBuffer();

        char[] string = "Hello client
public class Server {
public static void main( String[] args ) throws Throwable {
File f = new File( FILE_NAME );
FileChannel channel = FileChannel.open( f.toPath(), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE );
MappedByteBuffer b = channel.map( MapMode.READ_WRITE, 0, 4096 );
CharBuffer charBuf = b.asCharBuffer();
char[] string = "Hello client\0".toCharArray();
charBuf.put( string );
System.out.println( "Waiting for client." );
while( charBuf.get( 0 ) != '\0' );
System.out.println( "Finished waiting." );
}
}
".toCharArray();
        charBuf.put( string );

        System.out.println( "Waiting for client." );
        while( charBuf.get( 0 ) != '
public class Server {
public static void main( String[] args ) throws Throwable {
File f = new File( FILE_NAME );
FileChannel channel = FileChannel.open( f.toPath(), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE );
MappedByteBuffer b = channel.map( MapMode.READ_WRITE, 0, 4096 );
CharBuffer charBuf = b.asCharBuffer();
char[] string = "Hello client\0".toCharArray();
charBuf.put( string );
System.out.println( "Waiting for client." );
while( charBuf.get( 0 ) != '\0' );
System.out.println( "Finished waiting." );
}
}
' );
        System.out.println( "Finished waiting." );
    }
}

Client:

public class Client {

    public static void main( String[] args ) throws Throwable {
        File f = new File( FILE_NAME );
        FileChannel channel = FileChannel.open( f.toPath(), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE );

        MappedByteBuffer b = channel.map( MapMode.READ_WRITE, 0, 4096 );
        CharBuffer charBuf = b.asCharBuffer();

        //Prints 'Hello server'
        char c;
        while( ( c = charBuf.get() ) != 0 ) {
            System.out.print( c );
        }
        System.out.println();

        charBuf.put( 0, '
public class Client {
public static void main( String[] args ) throws Throwable {
File f = new File( FILE_NAME );
FileChannel channel = FileChannel.open( f.toPath(), StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE );
MappedByteBuffer b = channel.map( MapMode.READ_WRITE, 0, 4096 );
CharBuffer charBuf = b.asCharBuffer();
//Prints 'Hello server'
char c;
while( ( c = charBuf.get() ) != 0 ) {
System.out.print( c );
}
System.out.println();
charBuf.put( 0, '\0' );
}
}
' );
    }

}

Solution 2:

Une autre solution est d'utiliser Java Sockets à communiquer dans les deux sens entre les processus. Cela a l'avantage supplémentaire de permettre la communication sur un réseau très facilement. On pourrait faire valoir que c'est plus lent que d'utiliser les fichiers mappés en mémoire, mais je n'ai pas de critères de référence pour appuyer cette affirmation en place. Je ne poste pas de code pour la mise en œuvre de cette solution, car cela peut devenir très compliqué à mettre en place un réseau fiable protocole et est assez spécifique à l'application. Il ya beaucoup de bons sites de réseautage qui peut être trouvé avec la fonction de recherche rapide.

Maintenant les exemples ci-dessus sont, si vous voulez partager la mémoire entre deux processus différents. Si vous voulez juste pour lire/écrire à l'arbitraire de la mémoire dans le processus actuel, il y a quelques avertissements que vous devez savoir en premier. Cela va à l'encontre de l'ensemble de ce principe de la JVM et que vous vraiment ne devraient pas le faire dans le code de production. Vous ne respectez toutes les consignes de sécurité et peut très facilement crash de la JVM si vous n'êtes pas très prudent.

Cela étant dit, il est assez amusant d'expérimenter avec. Pour lire/écrire à l'arbitraire de la mémoire dans le processus actuel, vous pouvez utiliser le sun.misc.Unsafe classe. Il est présent sur toutes les machines virtuelles que je suis au courant et ont utilisé. Un exemple qui montre comment utiliser la classe peut être trouvé ici.

Distributed_cache est la meilleure solution pour répondre à vos exigences.

En informatique, un cache distribué est une extension de la notion traditionnelle de cache utilisé dans une seule localité. Un cache distribué peut s'étendre sur plusieurs serveurs, de sorte qu'il peut croître en taille et en transnationale capacité.

Quelques options:

Terre cuite permet aux threads dans un cluster de machines virtuelles à interagir les uns avec les autres à travers la JVM des limites à l'aide de la même intégré dans la JVM des installations de l'extension d'un cluster à l'échelle de sens

Oracle_Coherence est propriétaire d'unUn Java-base de données en mémoire de la grille, conçu pour avoir une meilleure fiabilité, l'évolutivité et les performances que les traditionnels de bases de données relationnelles les systèmes de gestion de

Ehcache est largement utilisé open source Java cache distribué pour objectif général la mise en cache, Java EE et de la lumière-poids des conteneurs. Il dispose d'une mémoire et un disque de magasins, de reproduire par copie et de l'invalider, auditeurs, la mise en cache des chargeurs, des cache les extensions, le cache, les gestionnaires d'exception, un gzip la mise en cache filtre de servlet, de détente, et de l'Api SOAP

Redis est une structure de données du serveur. Il est open-source, en réseau, en mémoire, et stocke les clés avec en option la durabilité.

Couchbase_Server est un open-source, distribué (shared-nothing architecture) multi-modèle NoSQL orientée document logiciel de base de données qui est optimisé pour les applications interactives. Ces applications peuvent servir à plusieurs utilisateurs simultanés par la création, le stockage, la récupération, l'agrégation, la manipulation et la présentation des données.

Utile messages:

Qu'est-ce que la terre Cuite?

Est en terre Cuite d'un cache distribué?

infoq article

Oui,

avec un programme intermédiaire, vous pouvez écrire et lire arbitraire emplacements de mémoire. Vous ne pouvez pas le faire uniquement en Java.

Par exemple, vous pouvez écrire un morceau de code C++ qui permet la lecture de l'arbitraire d'un emplacement de la mémoire et l'appeler via JNI. La même chose est vraie dans le sens inverse pour écrire à une adresse de mémoire.

Écrire une définition de la classe de première de la classe qui doit gérer cela, par exemple:

public class MemTest {
    public native byte[] readMemory(int address);
    public native void writeMemory(int address, byte[] values);
}

Puis vous le compilez. Ensuite, vous utilisez javah.exe (ou l'équivalent linux) pour générer un en-tête pour elle:

javah MemTest

Maintenant vous écrivez un .fichier cpp qui comprend que l'en-tête et définit les méthodes. La compilation de la DLL. Pour charger le .dll, vous pouvez utiliser la -Djava.de la bibliothèque.chemin de la JVM paramètre avec la valeur appropriée, ou d'un Système.loadLibrary().

Note de prudence: je ne recommande pas de faire cela. Il y a certainement de meilleures façons de faire ce que vous voulez faire.

Dangereux avec pivot hors de segment de mémoire

Que penser de l'utilisation Impropre à la copie de l'Objet d'octets à un chef de zone, puis quelques-comment passer un bon pointeur et le nom de la classe à la 2ème JVM qui va utiliser le pointeur et le nom de classe de copier et jeté hors de la mémoire pour un objet tas en 2ème de la JVM.
Ce n'est pas la même instance d'objet, mais une copie rapide, sans sérialisation.

public static Unsafe getUnsafe() {
    try {
        Field f = Unsafe.class.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        return (Unsafe)f.get(null);
    } catch (Exception e) { /* ... */ }
}

MyStructure structure = new MyStructure(); //create a test object
structure.x = 777;

long size = sizeOf(structure);
long offheapPointer = getUnsafe().allocateMemory(size);
getUnsafe().copyMemory(
            structure,      //source object
            0,              //source offset is zero - copy an entire object
            null,           //destination is specified by absolute address, so destination object is null
            offheapPointer, //destination address
            size
    ); //test object was copied to off-heap

Pointer p = new Pointer(); //Pointer is just a handler that stores address of some object
long pointerOffset = getUnsafe().objectFieldOffset(Pointer.class.getDeclaredField("pointer"));
getUnsafe().putLong(p, pointerOffset, offheapPointer); //set pointer to off-heap copy of the test object

structure.x = 222; //rewrite x value in the original object
System.out.println(  ((MyStructure)p.pointer).x  ); //prints 777

....

class Pointer {
    Object pointer;
}

alors maintenant, vous passez MyStructure et p de ((MyStructure)p.pointeur).x à une 2ème JVM, et vous devriez être capable de:

MyStructure locallyImported = (MyStructure)p.pointer;

Je peux imaginer un cas d'utilisation: supposons que vous avez 2 Microservices qui peuvent ou peuvent ne pas être en cours d'exécution dans la même serveur et un client de stratégie, peut-être mis en œuvre dans le conteneur du serveur d'applications, qui sait où les services sont déployés, dans le cas où il détecte le service demandé est en local, il peut utiliser un Dangereux base de client de service à la requête de l'autre service de manière transparente. Méchant, mais intéressant, j'aimerais voir les implications sur les performances de la non-utilisation du réseau, en contournant WebAPI (en appelant directement la manipulation de la manette) et pas de la sérialisation. Outre les paramètres du contrôleur dans ce cas, le contrôleur lui-même doit être fournie. Ne pensez même pas à la Sécurité.

des extraits de code emprunté à https://highlyscalable.wordpress.com/2012/02/02/direct-memory-access-in-java/