1 關於繼承：不可否認良好的抽象設計可以讓程式更清晰，**更看起來更好，但是她也是有損失的，在繼承體系中子類的建立會呼叫父類的建構函式，銷毀時會呼叫父類的析構函式，這種消耗會隨著繼承的深度直線上公升，所以不要過度的抽象和繼承。
2 物件的復合：物件的復合和繼承很相似，當乙個物件包含其他物件構造時也會引起額外的構造。關於這點可能會有很多人不解，認為這是不可避免的，舉個例子，你的乙個物件中用到陣列和字串，你是選擇string和vector還是char＊ 和c系的陣列呢，如果沒有用到c++stl庫提供的相關的高階用法，建議選擇後者。
3 建構函式：盡量用引數列表初始化代替引數，避免值傳遞初始化。
4 變數延時定義：從c系轉過來的仍保留著c的習慣，在函式第一行先把所有用到的變數都定義好，但是c是沒有執行時的消耗的，對於c++時不一樣的，對於c++物件的構造和銷毀時有消耗的，如果有大量的物件只在某個if條件的乙個分支中出現，那就會有50%的情況這些消耗是可以避免的。對於這點在乙個類中也是一樣的，如果成員中有成員只在某個時刻能用，就用指標代替，在構造物件時初始化成空指標，避免構造時呼叫他的建構函式。
5 虛函式：虛函式的底層實現是通過乙個虛函式表來實現的，因此有虛函式的類構造時必須先初始化虛函式表，函式呼叫時也必須先找到虛函式表，然後通過指標偏移找到相應的函式，並且如果虛繼承的存在會進一步增長這個過程，它是有執行時消耗的，所以避免濫用虛函式和虛繼承，盡可能的用模版設計來代替虛繼承把執行時的消耗提前到編譯期。
6 返回值優化：雖然c++編譯器會選擇性的進行rvo優化但是不是強制的，當函式有多個返回語句並且返回不通名稱的物件，函式過於複雜，返回物件沒有定義拷貝建構函式時，rvo優化是不會執行的，所以當函式返回乙個很大的物件時在不確定rvo優化會執行時，盡量避免值傳遞。
7 變數的定義：在定義變數時盡量避免型別的不匹配造成臨時變數的產生。
8 記憶體管理：c++記憶體管理的大權由我們自己掌握，對於專案中要頻繁申請和釋放的物件建議用簡單的記憶體池來管理，可以大大的降低頻繁申請和釋放記憶體帶來的消耗。
9 善用內聯：內聯函式不僅僅是簡單的函式呼叫似的優化，他還有乙個最大的優點就是，可以讓編譯期進行進行邊界**的執行環境優化，內聯把**拷貝到執行環境處避免了函式呼叫帶來的消耗，並且編譯期可以進行正常的編譯優化，而函式呼叫是不能實現的。
10 stl ：記住一點stl不是唯一的選擇，有時候也不是最好的選擇，合理選擇stl善用stl演算法。
11 快取：對於多次使用的計算結果及時快取，避免重複計算。
12 延時計算：對於不關心計算結果的計算過程盡量延時執行或者非同步去執行。
13 多執行緒：盡可能的使用無鎖式多執行緒開發，鎖是乙個非常消耗效能的東西，保證資料同步的手段有很多，***lite，原子操作都可已實現，如果迫不得已要儘量減少鎖的消耗，比如降低鎖的粒度，使用效能更高的鎖等等。
14 cpu快取：合理的利用cpu cache可以極大的提高**的執行效率，比如陣列中以每列遍歷和每行遍歷的區別。當然多執行緒環境下也要考慮它帶來的影響。
15 記憶體對齊：在進行網路程式設計時，最好對網路中傳送的資料快進行記憶體補齊，加快網路資料的讀區速度。
16 函式引數：用const引用代替值傳遞，如果函式引數過多，可以用物件來打包引數，減少引數過多帶來的效能消耗。
17 演算法:盡可能的優化你的演算法。
18 其他優化方案：位運算代替乘除法，字首運算子代替字尾運算等等。
ElasticSearch效能優化策略
一 伺服器部署演算法的基本思想 1 增加1 2臺伺服器，用於負載均衡節點 elasticsearch的配置檔案中有2個引數 node.master和node.data。這兩個參 數搭配使用時，能夠幫助提供伺服器效能。1.1 node.master false node.data true 該node...
Android效能優化策略
本篇主要是對 google推出的效能優化典範 進行乙個通篇的整理 主要在於一些具體的優化技巧 至於60fps 掉幀 gc 記憶體抖動 閾值 等等這些效能術語的概念裡面不做多概括，請自行查閱 本篇從以下幾點延伸擴充套件 systrace systrace 在android ddms 裡自帶，可以用來跟...
Hibernate效能優化策略
1 快取機制 a 基本快取 session快取 一級快取 session中儲存了乙個map id po po 持久化物件 b 二級快取 全域性快取 sessionfactory 1 過度使用的問題 記憶體會被過度占用，會導致系統效能急劇下降。2 使用條件 i 快取的資料比較穩定 變動不頻繁 如 部門...