碰到問題先別急，按下面的思路去套，先一步步地定位問題、細化問題。
千萬別在論壇、群里問，我的機器好慢怎么回事？我的機器內存泄露了怎么回事？
這類大而空的問題一點意義都沒有，其實誰都不知道。你要做的是用下面的思路、方法、工具去定位它
------------------------------
解決問題思路
Java程序問題（運行慢）
先通過 top 查看整個CPU資源使用情況；
通過top -Hp pid查看java進程的每一個線程占用CPU的情況；
如果有一個線程占用CPU過高，有兩種可能：
沒有內存了，Java垃圾回收線程不停地運行嘗試回收內存，但是每次無法收回，確認：
jstat -gcutil pid 1s 觀察10多秒鐘就能發現了，看是不是內存使用率接近100%了
類似于死循環（hash沖突攻擊），就是一個線程一直占用一個核的所有CPU資源（其實一個線程總是暫用一個核超過50%的資源都是不太正常的），解決：
用我課堂的checkPerf腳本，定位這個線程具體執行的任務（能具體到某一行），對應看代碼解決。
如果有很多線程，每個線程占用的CPU都不多，那基本是正常的。
如果死鎖：
jstack -l pid 多執行幾次，統計一下stack中總是在等待哪些鎖，可以對鎖id進行排序統計（sort uniq grep）
上面列出來的都是明顯的瓶頸，最可怕的是哪里都沒有明顯的瓶頸，哪里都要偷一點點資源走，這是可以試試JProfiler這樣更專業一點的工具，同時要配合自己對業務的了解來解決。
Java內存的問題，如果有內存泄露（就是執行完fgc/old gc后不能回收的內存不斷地增加）：
快速解決：jmap -histo:live pid 來統計所有對象的個數（String/char/Integer/HashEntry 這樣的對象很多很正常，主要是盯著你們公司的包名下的那些對象）
每隔一分鐘執行一次上面的命令，執行5次以上，看看你們公司報名下的對象數量哪個在一直增加，那基本上就是這個對象引起了泄露；
用課堂上的工具HouseMD來動態監控創建這個對象的地方（一般來說很多時候創建了這些對象把他們丟到一個HashMap然后就不管了），分析一下有沒有釋放！
上面的方法實在沒法定位就用: jmap -dump 導出整個內存（耗時間，需要很大的內存的機器才能對這個導出文件進行分析，會將JVM鎖住一段時間）
在Eclipse的插件EMA中打開這個文件（2G的物理文件需要4G以上的內存，5G以上的需要將近20G的內存來分析了）
盯著你們公司報名的那些對象，看看引用關系，誰拿著這些對象沒釋放（是否是必要的）
MySQL 數據庫的性能問題
大部分情況下是磁盤IO的問題（索引沒建好、查詢太復雜）；
索引問題的話分析慢查詢日志，explain 他們挨個解決。
偶爾也有數據庫CPU不夠的情況，如果并發高CPU不夠很正常，如果并發不高，那很可能就是group by/order by/random之類的操作嚴重消耗了數據庫的CPU
mysql -e "show full processlist" | grep -v Sleep | sort -rnk6 查看那些SQL語句執行的太長
拿出這個SQL語句分析他們的執行計劃: explain SQL 然后改進；
分析慢查詢日志，統計top10性能殺手的語句，挨個explain他們，然后改進（具體改進辦法具體分析，這里只談思路）
總結一下數據庫問題就只有這三招：show full processlist/分析慢查詢日志/explain（然后建好聯合索引）