學(xué)習(xí)理解運(yùn)行的程序的性能問題與學(xué)習(xí)debug是一樣不可避免的。很多人完成了需求以及功能，但是這個(gè)功能的耗時(shí)與占用內(nèi)存全然不管，導(dǎo)致了所寫的代碼很難受到他人的認(rèn)可。所以說理解性能問題，能幫助你升華你的代碼以及編程水平。

有可能你的客戶認(rèn)為你的一個(gè)系統(tǒng)或子系統(tǒng)運(yùn)行太慢了，或者一跑你的程序就瞬間把cpu的核擠爆了。你要想辦法去優(yōu)化它，去提升它的性能，或者更貼切的說去優(yōu)化你的邏輯以及算法。

你可能需要去構(gòu)建一個(gè)它為什么慢的思維模型，你可以用一個(gè)圖表工具或者打印運(yùn)行時(shí)間戳，去發(fā)現(xiàn)時(shí)間或資源真正被損耗的地方。有可能大部分時(shí)間是以某種形式華為費(fèi)在I/O上。發(fā)現(xiàn)昂貴的I/O和昂貴的10%代碼是構(gòu)建思維模型的一個(gè)好的開始。打開你windows的任務(wù)管理器，可以清晰的看到各個(gè)數(shù)據(jù)以及圖表。

計(jì)算機(jī)系統(tǒng)的性能優(yōu)很多個(gè)維度，很多資源會被消耗。第一種資源是“掛鐘時(shí)間”，即執(zhí)行程序的所有時(shí)間。記錄“掛鐘時(shí)間”是一件特別有價(jià)值的事情。有時(shí)候有些東西只是稍微多花費(fèi)了一點(diǎn)點(diǎn)時(shí)間，并且不會引爆什么問題，只有在特定的場景下才會引發(fā)crash，所以在你真實(shí)要處理的計(jì)算機(jī)環(huán)境中，多一些處理器時(shí)間可能會是更好的選擇。相似的內(nèi)存，網(wǎng)絡(luò)帶寬，數(shù)據(jù)庫或其他服務(wù)器訪問，可能最后都比處理器時(shí)間要更加昂貴。

競爭共享的資源被同步使用，一切都到后面都會是資源的爭奪，可能導(dǎo)致司索和互斥。死鎖是由于不恰當(dāng)?shù)耐胶驼埱筚Y源導(dǎo)致線程執(zhí)行能力的喪失?；コ馐菍τ谫Y源訪問的不恰當(dāng)安排。尤其是在多線程高并發(fā)的場合，忽略一些東西就會引來很大的麻煩。如果你可以預(yù)料到問題可能爆發(fā)的點(diǎn)，最好在你的項(xiàng)目開始前就采取措施來衡量線程爭搶。及時(shí)線程爭搶不發(fā)發(fā)生，對于優(yōu)先維護(hù)他們也是很有幫助的。

比如說對于循環(huán)的優(yōu)化，我相信大都數(shù)人循環(huán)寫完實(shí)現(xiàn)功能，一般不會再去思考如何提高他執(zhí)行循環(huán)的效率以及性能。我們總在寫循環(huán)，總在理所當(dāng)然的感覺循環(huán)不會出問題，但是卻并沒有以一種高尚的上帝視角來優(yōu)化，很多時(shí)候循環(huán)耗時(shí)是可怕的，跟遞歸一般。以下是一段中值濾波的代碼，有4個(gè)循環(huán)，在前面適當(dāng)?shù)奶砑雍甓x#pragma omp parallel for能夠多線程的去執(zhí)行這個(gè)循環(huán)，雖然只是一個(gè)細(xì)微的步驟，但是我覺得這個(gè)代碼已經(jīng)往優(yōu)雅處走。

同時(shí)建立合理的預(yù)警火災(zāi)機(jī)制，你可以視情況的嚴(yán)重性添加火災(zāi)等級水平，通過郵件或者app及時(shí)的抄送給相關(guān)的負(fù)責(zé)人，類似余監(jiān)視器，把這個(gè)監(jiān)視器打開，你就可以完全可控的掌管大局。