問題概述：
公司做的是BS應用。
之前我們的后台服務器程序是帶狀態的，用ehcache存儲登錄狀態；這兩天被我改成了redis存儲，應用本身不再存儲登錄狀態。
然后自測，我在測試某個很耗時間的網頁操作的時候，發現第一次請求的時候還比較快（這個請求會開200個iframe出來，每個iframe內部還有2個ajax請求）（期間瀏覽器會向服務器發送了大概600個請求），耗時1分鍾內；
然后第二次請求的時候，發現很多請求一直處於pending狀態（chrome的開發者工具可以看），等待很久也出不來頁面，就是一直轉圈加載，很有耐心的我等了10多分鍾才出來。
先是用chrome的開發者工具查看請求，以下面的一個ajax請求為例，
從開發者工具看到右邊的主要耗時在Waitting(TTFB)，那看來應該是我服務器有問題咯？
排查開始：
1、后台邏輯
這個請求的主要邏輯是：先過攔截器，攔截器根據cookie中帶的全局token去redis取登錄信息，判斷是否登錄來進行攔截；如果登錄了的話，到controller層后，主要是查數據庫，為了排除這部分影響，業務代碼被我注釋了，直接返回。
2、排除無關因素
2.1、先注釋掉業務邏輯代碼
2.2、再記錄下攔截器中從redis取數據花費時間：
3、跑了幾把后，日志記錄大概如下：
因為是業務邏輯馬上就返回，幾乎不耗時；
攔截器也耗時很少，大概是0,1,2這幾個值（局域網redis還挺快的）
4、開始問題測試
結果呢，發現現象還是一樣，第一次還比較快，后面就越來越慢。開始懷疑是不是tomcat的問題，
於是嘗試改成了nio、線程數也加大了
（上圖默認的http11，沒換成nio，要換的話，改成org.apache.coyote.http11.Http11NioProtocol）
參考：http://www.jianshu.com/p/8445645b3aff
5、加大tomcat線程池后的結果
還是差不太多，就是比之前是快了一點的感覺。
6、后邊跟同事一起分析的時候，同事說要不你把tab頁關了再試試，受到了啟發。
第一次請求的時候，瀏覽器的該網站進程（因為chrome瀏覽器是每個tab頁一個進程的）內存占用為600M；
第二次請求的時候，內存會飆到1200M左右；
第三次請求，貌似我那幾百個請求幾乎很多都在pengding狀態。
下面是測試結果：
6.1、首次打開網站時，內存占用為70M
6.2、跑第一次耗時操作
第一次任務跑完，內存上到了1200M，耗時50s，共600個請求左右。
6.3、跑第二次耗時操作
。。。。
。。。。
。。。。
等得時間太長了，所以無聊中看了下任務管理器（上面說了，因為chrome的tab頁是進程，所以可以看到）
內存已經快要到1800M了。
開發者工具如下：
可以發現有大量的pending請求，然后時間也已經過去了好幾分鍾（快6分鍾了，還沒有完結的跡象）
此時的服務器后台如何呢？
攔截器和業務邏輯方法依然很快。
。。。。
。。。。
。。。。
等啊等
終於，在700s，也就是11分鍾左右，終於結束了。坑啊
6.4、對頁面刷新后，再跑一次試試
F5刷新后，看看內存占用：
200M。還可以
那么我們再跑一次看看效果
可以看到，新的一次請求，在一分鍾內結束了。
總結：事到如今，問題已經很明顯，是瀏覽器tab頁（進程）占用內存過大后，發送的請求中pending狀態的請求的比例會顯著增加。具體原因未明，望解惑。
解決的辦法是F5刷新或者關掉tab頁重新打開。