tomcat內(nèi)存溢出問(wèn)題解決經(jīng)歷

前一段時(shí)間提交了一個(gè)產(chǎn)品版本給測(cè)試人員測(cè)試，測(cè)試結(jié)果簡(jiǎn)直出人意料！

測(cè)試一段時(shí)間后頁(yè)面就卡死了，當(dāng)時(shí)根據(jù)這個(gè)現(xiàn)象下意識(shí)的懷疑是卡到數(shù)據(jù)庫(kù)這一層，然后查看數(shù)據(jù)庫(kù)連接相關(guān)的參數(shù)，如意料之中的相似，連接數(shù)太多了！當(dāng)把數(shù)據(jù)庫(kù)連接數(shù)解決后，本以為這個(gè)bug解決了，但是...

測(cè)試一段時(shí)間后頁(yè)面又卡死了?。?！

打開(kāi)任務(wù)管理器，發(fā)現(xiàn)tomcat內(nèi)存超過(guò)了1.5G，而且tomcat關(guān)不掉！是什么原因?qū)е碌哪?？左思右想之后，想到了一個(gè)可能會(huì)導(dǎo)致tomcat內(nèi)存上漲的點(diǎn)，那就是多線程，然后翻代碼找線程池的配置，發(fā)現(xiàn)也沒(méi)什么可疑之處。

那就先解決下tomcat關(guān)不掉的問(wèn)題吧，百度...檢查代碼...幾十分鐘后找到了，在tomcat監(jiān)聽(tīng)器的銷毀方法(contextDestroyed)里沒(méi)有關(guān)閉線程池，這種情況下，由于線程池沒(méi)法關(guān)閉，進(jìn)而導(dǎo)致tomcat無(wú)法關(guān)閉的問(wèn)題。

將代碼改為：

public class InitListener implements ServletContextListener{
  private Logger logger = Logger.getLogger(InitListener.class);
  @Override
  public void contextInitialized(ServletContextEvent sce) {
    logger.info("啟動(dòng)tomcat");
  }
  @Override
  public void contextDestroyed(ServletContextEvent sce) {
    logger.info("關(guān)閉tomcat,關(guān)閉線程池");
    ClassPathXmlApplicationContext classPathXmlApplicationContext = new ClassPathXmlApplicationContext("classpath*:applicationContext.xml");
    ThreadPoolTaskExecutor myTaskExecutor = (ThreadPoolTaskExecutor) classPathXmlApplicationContext.getBean("myTaskExecutor");
    myTaskExecutor.shutdown();
  }
}

好了，tomcat關(guān)不掉的問(wèn)題是解決了。

接下來(lái)解決內(nèi)存溢出的問(wèn)題(先看日志)：

查看tomcat的日志發(fā)現(xiàn)，頁(yè)面每一次調(diào)用后臺(tái)接口Spring的配置文件都會(huì)初始化一遍，也就是每次請(qǐng)求spring都會(huì)重新注入一次bean，而且占用的內(nèi)存不會(huì)被回收！

然后我就想什么情況下會(huì)初始化spring的配置文件：tomcat啟動(dòng)的時(shí)候；通過(guò)關(guān)鍵字new出來(lái)的時(shí)候，即

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

然后就全局搜索代碼找，果然在過(guò)濾器里找到了，每次接口來(lái)就會(huì)new一個(gè)對(duì)象，多可怕的代碼，在心里一直罵自己當(dāng)時(shí)怎么想的！這次經(jīng)歷我會(huì)引以為戒，記下來(lái)也是告訴自己以后不要再犯類似的問(wèn)題。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。