當乙個程序呼叫open("dev/binder")時：驅動層對應的處理函式會建立
structbinder_proc ;binder_proc有４棵紅黑樹，這裡關心表示binder實體的nodes,binder**的refs_by_desc
structbinder_ref ;通過來自使用者空間的handle,可以找到對應的binder_ref, 通過binder_ref可以找到對應的binder_node, binder_node中包含binder_node所在程序的服務指標
binder_node和binder_ref的建立
binder_node和binder_ref的建立來著資料傳輸過程，根據資料的型別建立的。
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
node->min_priority = fp->flags & flat_binder_flag_priority_mask;
node->accept_fds = !!(fp->flags & flat_binder_flag_accepts_fds);
}case binder_type_handle:
case binder_type_weak_handle:
struct binder_ref *ref = binder_get_ref(proc, fp->handle,
fp->type == binder_type_handle);
new_ref = binder_get_ref_for_node(target_proc, ref->node);
if (new_ref == null)
fp->binder = 0;
fp->handle = new_ref->desc;
fp->cookie = 0;
binder_inc_ref(new_ref, fp->type == binder_type_handle, null);
}當server端呼叫addservice後，驅動會在servicemanager的refs_by_desc紅黑樹中掛上service的binder_ref節點；在server的nodes紅黑樹中掛上service的binder_node節點。
因此，在servicemanager的refs_bbinder_get_ref(proc, fp->handle,fp->type == binder_type_handle)y_desc紅黑樹上可以找到到handle對應的binder_ref節點。ref->node是binder的實體，該實體是由server建立的, 這樣就關聯了binder_ref和binder_node.
redis set底層資料結構
redis的集合物件set的底層儲存結構特別神奇，我估計一般人想象不到，底層使用了intset和hashtable兩種資料結構儲存的，intset我們可以理解為陣列，hashtable就是普通的雜湊表 key為set的值，value為null 是不是覺得用hashtable儲存set是一件很神奇的事...
C vector底層資料結構
vector 其底層資料結構是陣列，由於陣列的特點，vector也具有以下特性 1 o 1 時間的快速訪問 2 順序儲存，所以插入到非尾結點位置所需時間複雜度為o n 刪除也一樣 3 擴容規則 當我們新建乙個vector的時候，會首先分配給他一片連續的記憶體空間，如std vector vec，當通...
Redis底層資料結構？
福哥口訣法 簡鏈字跳整 壓快壓 sds synamic string 簡單動態字串。支援自動動態擴容的位元組陣列 list 鍊錶 雙端鍊錶。dict 字典。使用雙雜湊表實現的,支援平滑擴容的字典 zskiplist 跳躍表。附加了後向指標的跳躍表 intset 整數集合。用於儲存整數數值集合的自有結...