Dans un système en cours d'exécution, nous voyons beaucoup de "GC complet (système)" qui indique que quelqu'un déclenche system.gc (). p>
Y a-t-il un moyen de savoir où dans le code cela se produit? P>
J'ai effectué la recherche de toute la source disponible, mais rien trouvé suspect, il doit donc être quelque part, probablement une autre application qui fonctionne dans le même conteneur ou le même conteneur lui-même. P>
4 Réponses :
Vous pouvez modifier la classe d'exécution pour vous connecter où gc () est appelé à un fichier (system.gc () appels runtime.gc ())
Pour ce faire, éditer une copie, la compiler et l'ajouter à votre Cependant, un nombre élevé de GC complet est plus susceptible d'être dû à un espace de survivant insuffisant ou à un espace tenu complet. P> Pouvez-vous essayer d'exécuter p> -xbootclasspath / p: code> p>
Vous ne pouvez pas vraiment changer la classe d'exécution, autant que je sache, car GC () est une méthode native. Vous pouvez changer system.gc (), mais ce n'est pas le seul endroit qui peut appeler runtime.getruntime (). GC () - Un exemple est Sun.Management.MoryImpl. Bien sûr, une bibliothèque pourrait l'appeler de cette manière aussi pour que le système de connexion ne vous disait pas tout.
en Java, vous ne pouvez pas "appeler" le collecteur des ordures. Si vous voyez le Documentation lorsque vous appelez à la méthode system.gc (), la machine virtuelle prend simplement comme une suggestion pour exécuter le collecteur des ordures, mais aucune garantie est complexe. Est un processus interne qui sera appelé automatiquement même si vous n'appelez pas quand il a besoin d'espace dans la pile. P>
Si vous voyez beaucoup de GC complet, cela peut être un symptôme de l'application ne relâchant pas correctement les ressources correctement. Vous devez surveiller le tas pour voir quel est le problème p>
+1 Bon point. Dans mon cas, un outil a été utilisé pour analyser le problème et a déclaré "17 collections sur 449 (3 786%) ont été déclenchées par des appels System.GC ()".
Certaines bibliothèques que vous utilisez peut appeler explicite GC. Vous pouvez le désactiver avec -xx: -disableexplicitgc code> et jeter un oeil si elle arrête
complet gc code> dans les journaux p>
Bon point; De cette façon, je peux distinguer rapidement des appels de GC explicites et des invocations «hors mémoire».
Utilisez après le script de Brace et Jvisalvm Strong> avec Plugin BTrace Strard> révélera l'appelant de System.gc code> facilement.
// import all BTrace annotations
import com.sun.btrace.annotations.*;
// import statics from BTraceUtils class
import static com.sun.btrace.BTraceUtils.*;
// @BTrace annotation tells that this is a BTrace program
@BTrace
public class GCcaller {
// @OnMethod annotation tells where to probe.
// In this example, we are interested in entry
// into the Thread.start() method.
@OnMethod(
clazz="java.lang.System",
method="gc"
)
public static void func() {
// println is defined in BTraceUtils
// you can only call the static methods of BTraceUtils
println("about to start a System.gc!");
jstack();
}
}
Solution simple: démarrez votre application en mode de débogage et mettre un point d'arrêt de méthode à
system.gc () code> (et
runtime.gc () code> pour une bonne mesure).
@Aaron, vous avez plus de 50 questions sans réponse acceptée. Peut-être que vous pourriez suivre les réponses afin qu'ils soient acceptables.
Je vois ce que tu veux dire. Certaines de mes questions sont probablement trop complexes pour le cas; Les réponses existantes ne sont pas satisfaisantes (comme Stackoverflow.com/Questions / 6136769 / ... ou Stackoverflow.com/questions/6135570 / cyclique-tampon-avec-Reade Rs ).