Comment faire pour annuler le mappage d'un fichier à partir de la mémoire mappée à l'aide de FileChannel en java?

De la MappedByteBuffer javadoc:

Mappé octets de la mémoire tampon et le mappage de fichier qu'il représente restent valables jusqu'à ce que le tampon lui-même est le garbage collector.

Essayez d'appeler System.gc()? Encore, ce n'est qu'une suggestion pour la VM.

[WinXP,SunJDK1.6], j'avais mappé ByteBuffer prises de filechannel. Après lecture des posts enfin réussi à appeler un nettoyant grâce à la réflexion, sans soleil.* package importations. Plus de verrouillage de fichier est en attente.

modifier Ajouté JDK9+ code(Luc Hutchison).

private static void closeDirectBuffer(ByteBuffer cb) {
    if (cb==null || !cb.isDirect()) return;
    //we could use this type cast and call functions without reflection code,
    //but static import from sun.* package is risky for non-SUN virtual machine.
    //try { ((sun.nio.ch.DirectBuffer)cb).cleaner().clean(); } catch (Exception ex) { }

    //JavaSpecVer: 1.6, 1.7, 1.8, 9, 10
    boolean isOldJDK = System.getProperty("java.specification.version","99").startsWith("1.");  
    try {
        if (isOldJDK) {
            Method cleaner = cb.getClass().getMethod("cleaner");
            cleaner.setAccessible(true);
            Method clean = Class.forName("sun.misc.Cleaner").getMethod("clean");
            clean.setAccessible(true);
            clean.invoke(cleaner.invoke(cb));
        } else {
            Class unsafeClass;
            try {
                unsafeClass = Class.forName("sun.misc.Unsafe");
            } catch(Exception ex) {
                //jdk.internal.misc.Unsafe doesn't yet have an invokeCleaner() method,
                //but that method should be added if sun.misc.Unsafe is removed.
                unsafeClass = Class.forName("jdk.internal.misc.Unsafe");
            }
            Method clean = unsafeClass.getMethod("invokeCleaner", ByteBuffer.class);
            clean.setAccessible(true);
            Field theUnsafeField = unsafeClass.getDeclaredField("theUnsafe");
            theUnsafeField.setAccessible(true);
            Object theUnsafe = theUnsafeField.get(null);
            clean.invoke(theUnsafe, cb);
        }
    } catch(Exception ex) { }
    cb = null;
}

Idées ont été prises à partir de ces postes.

* Comment faire pour annuler le mappage d'un fichier à partir de la mémoire mappée à l'aide de FileChannel en java?

* Des exemples de la forcer à libérer de la mémoire natif direct ByteBuffer a alloué, à l'aide du soleil.misc.Dangereux?

* https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/apache/lucene/store/bytebuffer/ByteBufferAllocator.java#L40

Pour contourner ce bug en Java, j'ai eu à faire à la suivante, qui va travailler ok pour les petites et moyennes taille des fichiers:

    //first open the file for random access
    RandomAccessFile raf = new RandomAccessFile(file, "r");

    //extract a file channel
    FileChannel channel = raf.getChannel();

    //you can memory-map a byte-buffer, but it keeps the file locked
    //ByteBuffer buf =
    //       channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size());

    //or, since map locks the file... just read the whole file into memory
    ByteBuffer buf = ByteBuffer.allocate((int)file.length());
    int read = channel.read(buf);

    //.... do something with buf

    channel.force(false);  //doesn't help
    channel.close();       //doesn't help
    channel = null;        //doesn't help
    buf = null;            //doesn't help
    raf.close();           //try to make sure that this thing is closed!!!!!

La méthode couverts dans les autres réponses qui emploie ((DirectBuffer) byteBuffer).cleaner().clean() ne fonctionne pas sur JDK 9+ (même en forme de reflet) sans afficher un An illegal reflective access operation has occurred avertissement. Cela permettra d'arrêter complètement de travailler à l'avenir la version de JDK. Heureusement sun.misc.Unsafe.invokeCleaner(ByteBuffer) peut faire exactement la même appel pour vous, sans l'avertissement: (à partir de OpenJDK 11 source):

public void invokeCleaner(java.nio.ByteBuffer directBuffer) {
    if (!directBuffer.isDirect())
        throw new IllegalArgumentException("buffer is non-direct");

    DirectBuffer db = (DirectBuffer)directBuffer;
    if (db.attachment() != null)
        throw new IllegalArgumentException("duplicate or slice");

    Cleaner cleaner = db.cleaner();
    if (cleaner != null) {
        cleaner.clean();
    }
}

Être un sun.misc classe, il sera retiré à un certain point. Il est intéressant de noter tous les appels mais celle-ci, sun.misc.Unsafe sont estimés à partir directement à jdk.internal.misc.Unsafe (je ne sais pas pourquoi invokeCleaner(ByteBuffer) n'est pas mandaté de la même manière que toutes les autres méthodes, c'était probablement une omission accidentelle).

J'ai écrit le code suivant qui est en mesure de nettoyer/fermer/unmap DirectByteBuffer/MappedByteBuffer instances sur JDK 7/8, ainsi que JDK 9+, et cela ne donne pas le reflet d'avertissement:

private static boolean PRE_JAVA_9 = 
System.getProperty("java.specification.version","9").startsWith("1.");
private static Method cleanMethod;
private static Method attachmentMethod;
private static Object theUnsafe;
static void getCleanMethodPrivileged() {
if (PRE_JAVA_9) {
try {
cleanMethod = Class.forName("sun.misc.Cleaner").getMethod("clean");
cleanMethod.setAccessible(true);
final Class<?> directByteBufferClass =
Class.forName("sun.nio.ch.DirectBuffer");
attachmentMethod = directByteBufferClass.getMethod("attachment");
attachmentMethod.setAccessible(true);
} catch (final Exception ex) {
}
} else {
try {
Class<?> unsafeClass;
try {
unsafeClass = Class.forName("sun.misc.Unsafe");
} catch (Exception e) {
//jdk.internal.misc.Unsafe doesn't yet have invokeCleaner(),
//but that method should be added if sun.misc.Unsafe is removed.
unsafeClass = Class.forName("jdk.internal.misc.Unsafe");
}
cleanMethod = unsafeClass.getMethod("invokeCleaner", ByteBuffer.class);
cleanMethod.setAccessible(true);
final Field theUnsafeField = unsafeClass.getDeclaredField("theUnsafe");
theUnsafeField.setAccessible(true);
theUnsafe = theUnsafeField.get(null);
} catch (final Exception ex) {
}
}
}
static {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
@Override
public Object run() {
getCleanMethodPrivileged();
return null;
}
});
}
private static boolean closeDirectByteBufferPrivileged(
final ByteBuffer byteBuffer, final LogNode log) {
try {
if (cleanMethod == null) {
if (log != null) {
log.log("Could not unmap ByteBuffer, cleanMethod == null");
}
return false;
}
if (PRE_JAVA_9) {
if (attachmentMethod == null) {
if (log != null) {
log.log("Could not unmap ByteBuffer, attachmentMethod == null");
}
return false;
}
//Make sure duplicates and slices are not cleaned, since this can result in
//duplicate attempts to clean the same buffer, which trigger a crash with:
//"A fatal error has been detected by the Java Runtime Environment:
//EXCEPTION_ACCESS_VIOLATION"
//See: https://stackoverflow.com/a/31592947/3950982
if (attachmentMethod.invoke(byteBuffer) != null) {
//Buffer is a duplicate or slice
return false;
}
//Invoke ((DirectBuffer) byteBuffer).cleaner().clean()
final Method cleaner = byteBuffer.getClass().getMethod("cleaner");
cleaner.setAccessible(true);
cleanMethod.invoke(cleaner.invoke(byteBuffer));
return true;
} else {
if (theUnsafe == null) {
if (log != null) {
log.log("Could not unmap ByteBuffer, theUnsafe == null");
}
return false;
}
//In JDK9+, calling the above code gives a reflection warning on stderr,
//need to call Unsafe.theUnsafe.invokeCleaner(byteBuffer) , which makes
//the same call, but does not print the reflection warning.
try {
cleanMethod.invoke(theUnsafe, byteBuffer);
return true;
} catch (final IllegalArgumentException e) {
//Buffer is a duplicate or slice
return false;
}
}
} catch (final Exception e) {
if (log != null) {
log.log("Could not unmap ByteBuffer: " + e);
}
return false;
}
}
/**
* Close a {@code DirectByteBuffer} -- in particular, will unmap a
* {@link MappedByteBuffer}.
* 
* @param byteBuffer
*            The {@link ByteBuffer} to close/unmap.
* @param log
*            The log.
* @return True if the byteBuffer was closed/unmapped (or if the ByteBuffer
*            was null or non-direct).
*/
public static boolean closeDirectByteBuffer(final ByteBuffer byteBuffer,
final Log log) {
if (byteBuffer != null && byteBuffer.isDirect()) {
return AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
@Override
public Boolean run() {
return closeDirectByteBufferPrivileged(byteBuffer, log);
}
});
} else {
//Nothing to unmap
return false;
}
}

Notez que vous devez ajouter le requires jdk.unsupported à votre module descripteur dans un modulaire d'exécution sur JDK 9+ (nécessaire pour l'utilisation de Unsafe).

Votre pot peut également avoir besoin d' RuntimePermission("accessClassInPackage.sun.misc"), RuntimePermission("accessClassInPackage.jdk.internal.misc"), et ReflectPermission("suppressAccessChecks").

C'est drôle de voir autant de recommandations à faire ce que l'Article 7 dans "Effective Java" spécifiquement dit de ne pas faire. Une résiliation de la méthode comme quoi @Whome fait et pas de références à la mémoire tampon est ce qui est nécessaire. GC ne peut pas être forcé.
Mais cela n'empêche pas les développeurs d'essayer. Une autre solution de contournement que j'ai trouvé est d'utiliser WeakReferences de http://jan.baresovi.cz/dr/en/java#memoryMap

final MappedByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0, size);
....
final WeakReference<mappedbytebuffer> bufferWeakRef = new WeakReference<mappedbytebuffer>(bb);
bb = null;
final long startTime = System.currentTimeMillis();
while(null != bufferWeakRef.get()) {
if(System.currentTimeMillis() - startTime > 10)
//give up
return;
System.gc();
Thread.yield();
}

Si le fichier mappé en mémoire tampon de l'objet peut être garanti pour être admissible pour la collecte des ordures, vous n'avez pas besoin de GC l'ensemble de la VM pour obtenir le tampon de la mémoire mappée pour être libéré. Vous pouvez appeler le Système.runFinalization() . Ce qui fera appel à la méthode finalize() sur le fichier mappé en mémoire tampon d'objet (si il n'y a pas de références dans votre application threads) qui permettra de libérer la mémoire mappée.