Libère la mémoire de java pour le système d'exploitation au moment de l'exécution.

Question

Supposons que j'ai une application Java Swings, J'ai fixé le Heap minimum à 64MB et le Heap maximum à 2GB, Lorsque l'utilisateur démarre l'application, l'écran de connexion s'affiche. s'affichera, à ce moment l'application utilise 64MB, n'est-ce pas ? Depuis mon Windows 7, je peux voir que l'application java se voit allouer 64 Mo. dans le Memory Resource Monitor du système d'exploitation (en fait, c'est plus que 64 Mo car la JVM a besoin de mémoire pour ses tâches).

Ensuite, si l'utilisateur fait un travail très lourd, l'application utilise 2G. Puis l'utilisateur se déconnecte de l'application, l'écran de connexion s'affiche à nouveau (l'application n'est pas encore fermée). À ce moment-là, la mémoire réelle que l'application utilise 64MB (supposons qu'il s'agisse d'une application de gestion de la mémoire parfaite), mais avec le système d'exploitation, cette application utilise toujours 2G de RAM, je peux le voir sur le moniteur de ressources du système d'exploitation.

Je veux que mon application libère la mémoire pour le système d'exploitation lorsqu'elle n'a pas besoin d'utiliser une grande quantité de mémoire. Puis-je le faire au moment de l'exécution avec une application Java ?

Je veux dire lorsque mon application a besoin d'utiliser 64 Mo de RAM, alors le système d'exploitation ne lui donne que 64 Mo, quand elle a besoin de 2GB de ram, le système d'exploitation lui donne 2GB, ensuite, si elle a besoin de 64 Mo de RAM, le système d'exploitation lui donne à nouveau 64 Mo seulement, Je ne veux pas qu'il gaspille 2000MB - 64MB = 1936MB.

Je peux le faire ?

Merci,

Answer 1

Je veux que mon application libère la mémoire au système d'exploitation quand elle n'a pas besoin d'utiliser une grande mémoire. Puis-je le faire au moment de l'exécution avec une application Java ?

Non, tu ne peux pas.

Dans certaines circonstances, le GC libérera la mémoire au système d'exploitation de son propre chef, mais je ne connais pas de JVM qui permette à une application de demander au GC de le faire. De plus, le GC est plutôt conservateur à ce sujet car ... en règle générale ... la JVM fonctionnera plus efficacement avec plus de mémoire, et demander / rendre continuellement de la mémoire à l'OS est inefficace.

---

Notez que l'option de réglage GC -XX:MaxHeapFreeRatio peut être utilisé pour spécifier le ratio maximum entre le tas libre et le tas utilisé avant que la GC ne rende la mémoire. Cependant, il existe des complications. Par exemple, tous les GC disponibles ne respectent pas cette option. Si vous voulez essayer cette approche, je vous suggère de faire quelques recherches... et de ne pas vous attendre à des miracles.

Answer 2

J'ai posté les résultats de mes tests là-bas . Fondamentalement, MaxHeapFreeRatio n'est pas respecté par toutes les implémentations de GC, et, pour aggraver les choses, il semble nécessaire qu'il y ait suffisamment d'activité du tas pour le déclencher en temps voulu, c'est-à-dire que vous pourriez avoir besoin de 2 exécutions complètes de GC pour libérer effectivement la mémoire au système d'exploitation. Et si vous avez une empreinte mémoire de X Go, vous devez probablement allouer 1 ou 2 fois cette quantité afin de déclencher la réduction de taille du tas. Ou bien vous appelez System.gc() manuellement.

Si les performances ne sont pas un problème et que seule l'empreinte mémoire compte, essayez :

-XX:UseSerialGC -Xms16M -Xminf=5 -Xmaxf=10

Answer 3

Le serialgc dans hotspot rendra la mémoire... du moins il le faisait. Vos performances vont plonger.

Tous les garbage collectors de IBM J9 jvm libèrent la mémoire. Je ne suis pas sûr que ce jvm soit en téléchargement libre...

La meilleure réponse est : pourquoi êtes-vous concerné ? La mémoire est très bon marché de nos jours et la mémoire gratuite est de la mémoire gaspillée. Est-ce que c'est en fait un problème ? Le système d'exploitation met en page la mémoire supplémentaire inutilisée sur le disque de toute façon. La meilleure solution est de l'ignorer :)

Vous pourriez également envisager de rechercher sur Google un stockage hors du tas, peut-être Teracotta/eh cache.

EDITAR:

Je viens de remarquer dans JDK1.7u6, qu'en utilisant G1GC avec un petit Xms et un grand Xmx, le ramasseur d'ordures réduira la taille du tas après quelques ramassages où des objets en excès ont été libérés.

Answer 4

Vous pouvez disposer des objets et suggérer au ramasseur d'ordures de faire son travail, mais si le GC ne le juge pas nécessaire, la demande sera ignorée. Donc, en résumé, "non".

Notez que la mémoire attribuée aux applications Java est définie avant le démarrage de l'application et n'est pas réglable.

Answer 5

Essayez de faire passer certaines parties de votre code dans un thread séparé et de vous en débarrasser lorsque vous n'en avez plus besoin.