Experience in solving tomcat memory overflow problem

Some time ago, I submitted a product version to testers for testing, and the test results were simply unexpected!

After testing for a while, the page got stuck. Based on this phenomenon, I subconsciously suspected that it was stuck at the database layer. Then I checked the parameters related to the database connection. As expected, the number of connections was too large! After solving the problem of database connection number, I thought the bug was solved, but...

After testing for a while, the page got stuck again! ! !

I opened the task manager and found that the tomcat memory exceeded 1.5G, and tomcat could not be shut down! What is the cause? After thinking about it, I thought of a point that might cause the increase of tomcat's memory, that is, multi-threading. Then I looked through the code for the configuration of the thread pool, and found nothing suspicious.

Then let's solve the problem that tomcat can't be shut down first. Baidu... checked the code... and found it after dozens of minutes. The thread pool was not closed in the destruction method (contextDestroyed) of the tomcat listener. In this case, since the thread pool cannot be closed, tomcat cannot be shut down.

Change the code to:

public class InitListener implements ServletContextListener {
  private Logger logger = Logger.getLogger(InitListener.class);
  @Override
  public void contextInitialized(ServletContextEvent sce) {
    logger.info("Start tomcat");
  }
  @Override
  public void contextDestroyed(ServletContextEvent sce) {
    logger.info("Close tomcat, close thread pool");
    ClassPathXmlApplicationContext classPathXmlApplicationContext = new ClassPathXmlApplicationContext("classpath*:applicationContext.xml");
    ThreadPoolTaskExecutor myTaskExecutor = (ThreadPoolTaskExecutor) classPathXmlApplicationContext.getBean("myTaskExecutor");
    myTaskExecutor.shutdown();
  }
}

Well, the problem of Tomcat not being able to shut down has been solved.

Next, solve the memory overflow problem (see the log first):

Checking the tomcat log, I found that the Spring configuration file of the background interface is initialized every time the page calls it, that is, spring will re-inject the bean every time it is requested, and the occupied memory will not be recycled!

Then I wondered when the spring configuration file would be initialized: when tomcat is started; when the keyword new is used, that is,

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

Then I searched the code globally, and sure enough, I found it in the filter. Every time an interface came, a new object would be created. What a terrible code! I kept cursing myself in my heart for what I was thinking at the time! I will take this experience as a warning and write it down to tell myself not to make similar mistakes again in the future.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.