Erfahrung in der Lösung von Tomcat-Speicherüberlaufproblemen

Vor einiger Zeit habe ich Testern eine Produktversion zum Testen vorgelegt und die Testergebnisse waren einfach unerwartet!

Nach einer Weile des Testens blieb die Seite hängen. Aufgrund dieses Phänomens vermutete ich unbewusst, dass sie auf der Datenbankebene hängen blieb. Dann überprüfte ich die Parameter im Zusammenhang mit der Datenbankverbindung. Wie erwartet war die Anzahl der Verbindungen zu groß! Nachdem ich das Problem mit der Datenbankverbindungsnummer gelöst hatte, dachte ich, der Fehler sei behoben, aber ...

Nach längerem Testen blieb die Seite erneut hängen! ! !

Ich habe den Task-Manager geöffnet und festgestellt, dass der Tomcat-Speicher 1,5 GB überschritt und Tomcat nicht heruntergefahren werden konnte! Was ist die Ursache? Nachdem ich darüber nachgedacht hatte, fiel mir ein Punkt ein, der möglicherweise zu einer Vergrößerung des Tomcat-Speichers führt, nämlich Multithreading. Dann sah ich mir den Code für die Konfiguration des Thread-Pools an und fand nichts Verdächtiges.

Dann lösen wir zuerst das Problem, dass Tomcat nicht heruntergefahren werden kann. Baidu ... hat den Code überprüft ... und nach Dutzenden von Minuten festgestellt. Der Thread-Pool wurde in der Zerstörungsmethode (contextDestroyed) des Tomcat-Listeners nicht geschlossen. In diesem Fall kann Tomcat nicht heruntergefahren werden, da der Thread-Pool nicht geschlossen werden kann.

Ändern Sie den Code wie folgt:

öffentliche Klasse InitListener implementiert ServletContextListener {
  privater Logger logger = Logger.getLogger(InitListener.class);
  @Überschreiben
  public void KontextInitialisiert(ServletContextEvent sce) {
    logger.info("Tomcat starten");
  }
  @Überschreiben
  öffentliche Leere Kontext zerstört (ServletContextEvent sce) {
    logger.info("Tomcat schließen, Thread-Pool schließen");
    ClassPathXmlApplicationContext classPathXmlApplicationContext = neuer ClassPathXmlApplicationContext("classpath*:applicationContext.xml");
    ThreadPoolTaskExecutor myTaskExecutor = (ThreadPoolTaskExecutor) classPathXmlApplicationContext.getBean("myTaskExecutor");
    myTaskExecutor.shutdown();
  }
}

Nun, das Problem, dass Tomcat nicht heruntergefahren werden konnte, wurde gelöst.

Lösen Sie als Nächstes das Problem des Speicherüberlaufs (siehe zuerst das Protokoll):

Beim Überprüfen des Tomcat-Protokolls habe ich festgestellt, dass die Spring-Konfigurationsdatei der Hintergrundschnittstelle bei jedem Aufruf durch die Seite initialisiert wird. Das heißt, Spring fügt die Bean bei jeder Anforderung erneut ein und der belegte Speicher wird nicht wiederverwendet!

Dann habe ich mich gefragt, wann die Spring-Konfigurationsdatei initialisiert wird: wenn Tomcat gestartet wird; wenn das Schlüsselwort new verwendet wird, das heißt,

ClassPathXmlApplicationContext classPathXmlApplicationContext = new ClassPathXmlApplicationContext("classpath*:applicationContext.xml");

Dann habe ich den Code global durchsucht und tatsächlich habe ich ihn im Filter gefunden. Jedes Mal, wenn eine Schnittstelle kam, wurde ein neues Objekt erstellt. Was für ein schrecklicher Code! Ich habe mich in meinem Herzen immer wieder für das verflucht, was ich damals gedacht habe! Ich werde diese Erfahrung als Warnung betrachten und sie aufschreiben, um mir selbst zu sagen, dass ich in Zukunft ähnliche Fehler nicht noch einmal machen werde.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.