Shulou(Shulou.com)06/02 Report--

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

After testing for a period of time, the page was jammed. At that time, according to this phenomenon, we subconsciously suspected that it was stuck to the database layer, and then check the database connection-related parameters, as expected, the number of connections is too many! When the number of database connections was solved, I thought the bug was solved, but.

After testing for a period of time, the page is stuck again!

Open the task manager and find that the tomcat memory is more than 1.5g, and the tomcat cannot be turned off! What is the cause? After thinking about it, I thought of a point that might lead to a rise in tomcat memory, that is, multithreading, and then looked through the code to find the configuration of the thread pool, and found that there was nothing suspicious.

Then first solve the problem that tomcat can't be turned off, Baidu. Check the code. It was found dozens of minutes later that the thread pool was not closed in the destroy method (contextDestroyed) of the tomcat listener. In this case, the thread pool could not be closed, which led to the problem that tomcat could not be closed.

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 ();}}

All right, the problem that tomcat can't turn off is solved.

Next, solve the problem of memory overflow (take a look at the log first):

Looking at the log of tomcat, it is found that every time the page calls the background interface Spring, the configuration file will be initialized, that is, every time spring is requested, bean will be re-injected, and the memory occupied will not be reclaimed!

Then I wondered under what circumstances the configuration file of spring would be initialized: when tomcat starts; when it comes out through the keyword new, that is

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

Then the global search code was found, and sure enough, it was found in the filter. Every time the interface came, it would new an object. What a terrible code, I kept scolding myself in my heart what I thought at that time! I will take this experience as a warning, and write it down to tell myself not to do similar problems in the future.

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.