1、請求響應慢問題

1.資料庫-慢查詢sql-是否建索引-sql是否能優化（用explain查詢sql執行計劃） 2.資料是否走快取-快取是否被擊中（如果沒有被擊中，說明最後查詢的還是資料庫） 3.如果呼叫了第三方介面-是否介面響應慢 4.業務邏輯是否可以簡化 5.是否有io阻塞（有可能是快取中某一個key被多次擊中並且key對應的value非常大）linux io命令或jprofiler 6.表資料過大，採用分庫分表 7.使用cdn（Content Delivery Network，即內容分發網路） 8.動靜分離（靜態資源部署在負載均衡上）及靜態資源壓縮（js、css） 9.增加不同的域名（一個域名的連結數是一定的） 10.程式連結方式：長連結（但是非常佔用系統記憶體，伺服器能建立長連線數也是一定的，伺服器端壓力大，客戶端無壓力），相對於tcp/ip的短連結，長連結建立後是不會被斷開的，節省建立連線和斷開的時間，適合內網應用 11.讀寫分離不是好的策略，兩個以上寫資料伺服器都同步讀伺服器的資料時，效能變慢，此方法不能橫向擴充套件 最大的瓶頸是io：網路io或檔案io

2、記憶體佔用大問題

1.多餘的日誌列印，將影響程式執行，列印日誌是阻塞操作，將終止程式開始寫檔案（多執行緒？）

3、記憶體溢位（linux系統記憶體）

http://itindex.net/detail/51440-java-記憶體-溢位

http://itindex.net/detail/46984-解密-java-記憶體

http://www.2cto.com/kf/201111/111079.html

4、堆疊溢位（堆疊是jvm中的一塊區域，所以一定是jvm、gc的問題）

其他

http://blog.csdn.net/lilu_leo/article/details/8115612

http://www.oschina.net/translate/9_fallacies_java_performance

https雙向認證解決引數篡改照成的csrf漏洞

http://edison0663.iteye.com/blog/996526

btrace 日誌監控

netty 非同步長連線

高效能的mysql

effective in java

構建高效能web站點

java虛擬機器原理

http權威指南

https://ruby-china.org/topics/10977 單元測試

王垠

http://ifeve.com/  原阿里同事的技術部落格

http://ju.outofmemory.cn/entry/100977

http://linux.cn/article-4126-1.html 日誌歸檔

新計費：

使用springtask代替quartz，由於叢集部署，需要zookeper做分散式鎖 防止兩個主機都執行了此定時任務

springbatch做批處理

cto面試：

頁面效能優化 linux優化 程式優化 資料庫優化 應用伺服器怎麼優化 JVM優化 spring aop ioc實現 設計模式 對開源軟體的看法 hbase hadoop redis 系統設計 表、程式設計 好處 底層協議http tcp/ip 分散式系統 junit 單元測試的覆蓋率是怎麼實現的