diff --git a/4 Tree/3-平衡树AVL/README.md b/4 Tree/3-平衡树AVL/README.md
index cacf95a..f901c47 100644
--- a/4 Tree/3-平衡树AVL/README.md	
+++ b/4 Tree/3-平衡树AVL/README.md	
@@ -1,9 +1,50 @@
+## 自平衡二叉查找树（AVL tree）
+
+自平衡二叉查找树（AVL tree）: 首先也是二次查找树，其实 任何2个子树的高度差不大于1
+在删除，插入的过程中不断调整子树的高度，保证平均和最坏情况下都是O(logn)
+
+Adelson-Velskii 和 Landis 1962年 创造。
+
+1） 平衡因子 -1 0 1 节点是正常的。平衡因子 = 左子树高度-右字数高度
+2） 除此之外的节点是不平衡的，需要重新平衡这个树。也就是AVL旋转
+
+
+AVL 实际使用案例
+
+* LLVM 的 ImmutableSet，其底层的实现选择为 AVL 树
+* 《一种基于二叉平衡树的P2P覆盖网络的研究》论文
+
+
+
+
+## 插入节点
+
+a: 左旋转(RR型：节点x的右孩子的右孩子上插入新元素）平衡因子由-1 -》-2 时，需要绕节点x左旋转
+b：右旋转(LL型：节点X的左孩子的左孩子上插入新元素） 平衡因子有1-》2，右旋转
+c: 先左后右旋转:(LR型:树中节点X的左孩子的右孩子上插入新元素） 平衡因子从1变成2后，就需要 先绕X的左子节点Y左旋转，接着再绕X右旋转
+d: 先右后左旋转：(RL型:节点X的右孩子的左孩子上插入新元素) 
+
+
+		6	  6                  6              6           
+	   /		\           	/                \
+	  5          7	           3                  9
+	/          	  \             \                 /
+   3               8             5               7
+    (LL型)     （RR）            (LR)            (RL)    
+
+
+## 删除节点
+
+
+
+
+可以看到，为了保证高度平衡，插入和删除操作代价增加
+
+
+## AVL 实现过程中的问题
+
 
-### AVL 实现过程中的问题
 
 
 
-### AVL 实际使用案例
 
- * LLVM 的 ImmutableSet，其底层的实现选择为 AVL 树
- * 《一种基于二叉平衡树的P2P覆盖网络的研究》论文
\ No newline at end of file
diff --git a/4 Tree/4-字典树Trie/字典树.md b/4 Tree/4-字典树Trie/字典树.md
index 4526528..5a33c3a 100644
--- a/4 Tree/4-字典树Trie/字典树.md	
+++ b/4 Tree/4-字典树Trie/字典树.md	
@@ -34,9 +34,10 @@ trie树把每个关键字保存在一条路径上，而不是一个节点中
 ### trie树存储结构和基本操作
 
 最简单实现 ---- 26个字母表 a-z (没有考虑数字，大小写，其他字符如=-*/)
-
 子树用数组存储，浪费空间；如果系统中存在大量字符串，且这些字符串基本没有公共前缀，trie树将消耗大量内存  
-如果用链表存储，查询时需要遍历链表，查询效率有所降低  
+如果用链表存储，查询时需要遍历链表，查询效率有所降低
+
+
 
 ```
 define ALPHABET_NUM 26
diff --git a/4 Tree/7-B数/B树.md b/4 Tree/7-B数/B树.md
index 8dfbcb8..b47b461 100644
--- a/4 Tree/7-B数/B树.md	
+++ b/4 Tree/7-B数/B树.md	
@@ -14,3 +14,67 @@
 5. 有k个关键字的页节点包含k+1个孩子
 
 也就是说：`根节点到每个叶节点的路径长度都是相同的。`
+
+
+
+## 数据结构
+
+
+```
+typedef struct Item{
+     int key;
+     Data data;
+}
+
+#define m 3 //B树的阶
+
+
+typedef struct BTNode{
+    int degree; //B树的度
+    int keynums; //每个节点key的个数
+     Item  items[m];
+     struct BTNode *p[m];
+}BTNode,* BTree;
+
+
+typedef struct{
+     BTNode *pt; //指向找到的节点
+     int i; 	// 节点中关键字的序号 (0,m-1)
+     int tag; 	//1:查找成功，0：查找失败
+}Result;
+
+
+Status btree_insert(root,target)//插入B树节点
+Result btree_find(root,target)//查找B树节点
+Status btree_delete(root,target)//删除B树节点
+```
+
+
+## 插入B树节点
+
+
+
+
+## 查找B树节点
+
+
+
+
+## 删除B树节点
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/4 Tree/9-红黑树 R-B tree/红黑树.md b/4 Tree/9-红黑树 R-B tree/红黑树.md
index 818062d..b12a7a8 100644
--- a/4 Tree/9-红黑树 R-B tree/红黑树.md	
+++ b/4 Tree/9-红黑树 R-B tree/红黑树.md	
@@ -3,7 +3,6 @@
 
 ### 应用场景
 
-
 java 中 HashMap 的底层实现，当HashMap中元素大于8个时，HashMap底层存储实现改为红黑树，以提高元素搜索速度。
 关于 HashMap 实现解析参考 [这里](.../Hash Table/HashMap in Java.md)
 
diff --git a/4 Tree/huffman tree/赫夫曼编码.md b/4 Tree/huffman tree/赫夫曼编码.md
index b121e98..8e641a6 100644
--- a/4 Tree/huffman tree/赫夫曼编码.md	
+++ b/4 Tree/huffman tree/赫夫曼编码.md	
@@ -46,4 +46,7 @@ struct node{
 
 1. 读取文件头  
 2. 遍历编码后的bits,从赫夫曼树的根节点出发，遇到0，进入左子树，遇到1进入右子树，直到叶节点  
+
+
+
   
diff --git a/5 Graph/README.md b/5 Graph/README.md
index 259cfff..7fe21e1 100644
--- a/5 Graph/README.md	
+++ b/5 Graph/README.md	
@@ -63,3 +63,7 @@ A*
 ### 参考
 
 https://www.jiqizhixin.com/articles/2019-05-16-14
+
+
+
+