Fichiers mappés en mémoire en Java

Question

J'ai essayé d'écrire du code Java très rapide qui doit faire beaucoup d'E / S. J'utilise un fichier mappé en mémoire qui renvoie un ByteBuffer:

public static ByteBuffer byteBufferForFile(String fname){
    FileChannel vectorChannel;
    ByteBuffer vector;
    try {
        vectorChannel = new FileInputStream(fname).getChannel();
    } catch (FileNotFoundException e1) {
        e1.printStackTrace();
        return null;
    }
    try {
        vector = vectorChannel.map(MapMode.READ_ONLY,0,vectorChannel.size());
    } catch (IOException e) {
        e.printStackTrace();
        return null;
    }
    return vector;
}

Le problème que je rencontre est que la méthode ByteBuffer .array () (qui devrait renvoyer un tableau byte []) ne fonctionne pas pour les fichiers en lecture seule. Je veux écrire mon code pour qu'il fonctionne avec les tampons de mémoire construits en mémoire et les tampons lus sur le disque. Mais je ne veux pas encapsuler tous mes tampons dans une fonction ByteBuffer.wrap () car je crains que cela ne ralentisse les choses. J'ai donc écrit deux versions de tout, l'une qui prend un octet [], l'autre qui utilise un ByteBuffer.

Devrais-je tout emballer? Ou devrais-je tout écrire en double?

Answer 1

Quelqu'un a-t-il réellement vérifié si ByteBuffers créé par le support de mappage de mémoire appelait .array () , indépendamment de readonly / readwrite?

D'après ce que je peux dire, la réponse est NON . La capacité de ByteBuffer de renvoyer un tableau direct byte [] via ByteBuffer.array () est garantie par la présence de ByteBuffer .hb ( octet [] ), qui est toujours défini sur null lors de la création d'un MappedByteBuffer .

Ce qui est un peu nul pour moi, parce que j'espérais faire quelque chose de similaire à ce que l'auteur de la question voulait faire.

Answer 2

Il est toujours bon de ne pas réinventer les roues. Apache a fourni une belle bibliothèque pour effectuer des opérations d'E / S. Consultez http://commons.apache.org/io/description.html .

Voici le scénario qu'il sert. Supposons que vous ayez des données que vous auriez préférez garder en mémoire, mais vous ne savez pas à l'avance combien de données il va être. S'il y en a trop, vous voulez l'écrire sur le disque au lieu de monopoliser la mémoire, mais vous ne voulez pas écrire sur le disque avant de besoin, car le disque est lent et constitue une ressource nécessitant un suivi pour nettoyage.

Vous créez donc un tampon temporaire et commencez à écrire dans celui-ci. Si / quand vous atteindre le seuil de ce que vous voulez garder en mémoire, vous devrez créer un fichier, écrire ce qui est dans la mémoire tampon dans ce fichier et écrire tout les données suivantes dans le fichier au lieu du tampon.

C’est ce que DeferredOutputStream fait pour vous. Il cache tout le bazar autour du point de commutation. Tout ce que vous avez à faire est de créer le flux différé en premier lieu, configurez le seuil, puis juste écrivez à votre guise.

EDIT: Je viens de faire une petite recherche à l'aide de Google et j'ai trouvé ce lien: http://lists.apple.com/archives/java-dev /2004/Apr/msg00086.html (Lecture / écriture rapide de fichiers). Très impressionnant.

Answer 3

Le fait d’emboîter des octets [] ne ralentira pas les choses ... il n’y aura pas d’immenses copies de tableaux ni d’autres petits maux de performances. Depuis les JavaDocs: java.nio.ByteBuffer .wrap ()

  

Entoure un tableau d'octets dans un tampon.

     

Le nouveau tampon sera sauvegardé par le tableau d'octets donné; , c'est-à-dire   les modifications apportées à la mémoire tampon entraîneront   le tableau à modifier et vice   vice versa. La capacité du nouveau tampon et   La limite sera array.length, sa   la position sera zéro, et sa marque   sera indéfini. Son tableau de support   sera le tableau donné, et son tableau   le décalage sera nul.

Answer 4

L'utilisation de la fonctionnalité ByteBuffer.wrap () n'impose pas une charge importante. Il alloue un objet simple et initialise quelques entiers. Écrire votre algorithme contre ByteBuffer est donc votre meilleur choix si vous devez travailler avec des fichiers en lecture seule.