Fuite de mémoire JavaFX 8 lors du masquage de la scène
J’ai une application JavaFX qui réduit au minimum lorsque vous appuyez sur le bouton X. J’ai surveillé l’application via VisualVM pour les tendances de la mémoire.
La partie étrange est que, lorsque l’application est ouverte, ou réduite à la barre des tâches, la mémoire est toujours reconstituée dans la mémoire initiale utilisée. Cependant, lorsqu’il est réduit au minimum dans la barre d’état ( stage.hide() , systemTray.show() ), la mémoire est GCed, mais dans une tendance ascendante (fuite).
Dans VisualVM, l’espace de l’ancienne génération ne cesse de croître et, une fois qu’il atteint son maximum après un certain temps, l’application ne répond plus et le processeur atteint 80%.
Je remarque que si je stage.show() sur l’application en double-cliquant sur l’icône de la barre d’état, etc., GC stage.show() tout à la normale . Cependant, si elle est laissée pendant de longues périodes, elle échouera simplement à atteindre l’ancienne génération.
- Java simultané et parallèle GC
- Comment fonctionne le ramasse-miettes Garbage-First?
- Pouvez-vous obtenir des statistiques GC de base en Java?
Un vidage de tas indique que javafx.scene.Scene#7 et javafx.scene.Node[]#2 ont le plus d’espace disponible. Les deux n’apparaîtront pas si la scène n’est pas cachée. Sous références, cela montre this[] -> dirtyNodes() .
this - value: javafx.scene.Node[] #2 <- dirtyNodes - class: javafx.scene.Scene, value: javafx.scene.Node[] #2 <- value - class: javafx.scene.Node$ReadOnlyObjectWrapperManualFire, value: javafx.scene.Scene #7
Quelle en est la cause et comment puis-je résoudre ce problème?
Je n’ai jamais trouvé et répondu à cela. Au lieu de cela, je voudrais annuler le noeud masqué et le restaurer à nouveau. Pour les nœuds dynamics / multiples nœuds intensifs, j’ai créé une carte de hachage pour les stocker en mémoire.
Cela est devenu une habitude pour moi dans javafx8 de disposer de tous les graphiques et de les réaffecter à la dissimulation et à la visualisation depuis la carte de hachage. L’utilisation supplémentaire de mémoire et de processeur est négligeable sur les ordinateurs de bureau modernes. En utilisant cette méthode, j’ai eu 0 applications d’utilisation du processeur et des applications à faible mémoire (~ 100m) en cours d’exécution lorsqu’elles étaient masquées sur win8 / 10.
Java a des fonctionnalités comme Weak Reference: https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html
Référence logiciel : https://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html
ils vous permettent de cibler spécifiquement la machine virtuelle – >> les éléments à récupérer.
en outre, il existe également une API de concurrence http://winterbe.com/posts/2015/04/07/java8-concurrency-tutorial-thread-executor-examples/
qui utilise le service d’exécution et le regroupement de threads.
et pour les applications ressortingctives en mémoire en java, le logiciel doit appeler
System.gc() // garbage collector
à intervalles indépendamment de son invocation automatique
Vous pouvez utiliser la classe Runtime pour planifier les équilibreurs de charge du projet https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html.
public Process exec(Ssortingng command) throws IOException //-------------------------------------------------------- Executes the specified ssortingng command in a separate process. public void gc() //---------------------------------------------------------- Runs the garbage collector. Calling this method suggests that the Java virtual machine expends effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects This is a convenience method. An invocation of the form exec(command) behaves in exactly the same way as the invocation exec(command, null, null).
le threading a toujours été un problème avec les applications gourmandes en mémoire et, dans JavaFX, chaque composant d’une scène est étroitement lié à une scène, mais il semble être lié de manière lâche à la mise en œuvre.
Si la durée d’exécution est longue, il est préférable de gérer certaines tâches gourmandes en ressources processeur du côté natif (JNI). De plus, une architecture PROPRE bénéficierait