feat: init

xiaomeng79 · xiaomeng79 · commit bef0860c06c2 · 2025-05-16T09:13:48.000+08:00
diff --git a/01语言/1go/10内存管理.md b/01语言/1go/10内存管理.md
@@ -48,26 +48,54 @@
 - 执行栈：每个 goroutine 都包含自己的执行栈，这些执行栈上包含栈上的变量及指向分配的堆内存区块的指针。
 - 寄存器
 
-#### GC
-
-- Go1.3采用标记清除法， Go1.5采用三色标记法，Go1.8采用三色标记法+混合写屏障。
-
-- 一次完整的GC分为四个阶段：
-    - 准备标记（需要STW），开启写屏障。
-    - 开始标记
-      - 在进入 GC 的三色标记阶段的一开始，所有对象都是白色的。
-      - 遍历根节点集合里的所有根对象，把根对象引用的对象标记为灰色，从白色集合放入灰色集合。
-      - 遍历灰色集合，将灰色对象引用的对象从白色集合放入灰色集合，之后将此灰色对象放入黑色集合
-      - 重复第三步, 直到灰色集合中无任何对象。
-      - 回收白色集合里的所有对象，本次垃圾回收结束。
-    - 标记结束（STW），关闭写屏障
-    - 清理（并发）
-- 基于插入写屏障和删除写屏障在结束时需要STW来重新扫描栈，带来性能瓶颈。混合写屏障分为以下四步：
-    - GC开始时，将栈上的全部对象标记为黑色（不需要二次扫描，无需STW）；
-    - GC期间，任何栈上创建的新对象均为黑色
-    - 被删除引用的对象标记为灰色
-    - 被添加引用的对象标记为灰色
-    - 总而言之就是确保黑色对象不能引用白色对象，这个改进直接使得GC时间从 2s降低到2us。
+#### 三色标记原理​​
+​- ​白色​​：初始状态，表示对象未被访问，可能为垃圾。
+​- ​灰色​​：对象被标记为可达，但其引用的子对象尚未检查。
+​​- 黑色​​：对象及其所有子对象均被检查，确定为存活对象。
+
+## GC 核心流程
+
+### 1. 标记准备阶段（STW）
+- **暂停所有用户协程**（STW），确保一致性。
+- **扫描根对象**：  
+  遍历栈、全局变量、寄存器等根对象，直接可达的对象标记为**灰色**，加入待处理队列。
+- **启用写屏障**：  
+  为后续并发标记阶段捕获对象引用变更。
+
+### 2. 并发标记阶段
+- **恢复用户协程**，GC线程与用户程序并发运行。
+- **处理灰色队列**：  
+  - 取出灰色对象，遍历其引用的子对象。  
+  - 若子对象为白色，则将其标记为灰色并加入队列。  
+  - 当前灰色对象标记为黑色。  
+- **写屏障监控**：  
+  - 用户程序修改对象引用时，触发混合写屏障（Hybrid Write Barrier）。  
+  - 若黑色对象引用白色对象，屏障将白色对象标记为灰色（防止漏标）。
+
+### 3. 标记终止阶段（STW）
+- **再次暂停用户协程**，确保所有灰色对象处理完毕。
+- 完成剩余标记工作，确认所有存活对象均为黑色。
+
+
+### 4. 并发清除阶段
+- 回收所有白色对象（垃圾）的内存。
+- 用户程序恢复运行。
+
+---
+
+## 关键机制
+
+### 混合写屏障（Hybrid Write Barrier）
+- **插入屏障**：  
+  黑色对象引用白色对象时，将白色对象标记为灰色。
+- **删除屏障**：  
+  若被删除引用的对象为灰色或白色，则标记为灰色（Go 1.8+优化后主要依赖插入屏障）。
+- **目的**：  
+  确保并发标记期间，用户代码修改引用关系不会导致存活对象被误回收。
+
+### 并发优化
+- GC线程与用户协程交替运行（基于Goroutine调度器）。  
+- 利用CPU多核并行处理标记任务，缩短暂停时间。
 
 #### 有了 GC，为什么还会发生内存泄露
 - 预期能被快速释放的内存因被根对象引用而没有得到迅速释放
diff --git a/01语言/1go/12优化.md b/01语言/1go/12优化.md
@@ -1,17 +1,15 @@
 ## 优化
 
-#### go 优化
-
-1. 注重锁的使用，尽量做到锁变量而不要锁过程 ,可以使用CAS机制，则使用CAS操作
-2. 针对热点代码要做针对性优化
-3. 不要忽略 GC 的影响，尤其是高性能低延迟的服务,使用对象池,声明切片定义容量
-4. 尽量避免反射，在高性能服务中杜绝反射的使用
-5. 有些情况下可以尝试调优“GOGC”参数
-6. 新版本稳定的前提下，尽量升级新的 Go 版本
-7. 对频繁分配的小对象，使用 sync.Pool 对象池避免分配
-8. 自动化的 DeepCopy 是非常耗时的，其中涉及到反射，内存分配，容器(如 map)扩展等，大概比手动拷贝慢一个数量级
-9. 在开发环境开启 net/http/pprof，方便实时 pprof
-10. 将所有外部IO(网络IO，磁盘IO)做成异步
+#### go 内存优化
+
+1. ​​减少堆内存分配​，尽量到栈上。
+2. 复用对象（对象池）​
+3. 预分配切片/Map​
+4. 数据结构优化
+   1. 调整字段顺序​​：利用内存对齐减少填充空隙。
+   2. 使用unsafe 手动管理内存，如解析协议时避免类型转换。
+5. 调整GC触发阈值
+6. 长期存活的对象提升为全局变量，避免反复分配。
 
 
 #### 参数化分析
diff --git a/01语言/1go/6注意点.md b/01语言/1go/6注意点.md
@@ -381,4 +381,33 @@ b := append([]int(nil), a...) // 将元素追加到新切片
 2. JSON 序列化，但效率较低，gob效率高点
 3. 使用第三方库，github.com/jinzhu/copier
 
+### io.CopyBuffer
+```go
+func Transport(rw1, rw2 io.ReadWriter) error {
+	errc := make(chan error, 1)
+	go func() {
+		errc <- CopyBuffer(rw1, rw2, bufferSize)
+	}()
+
+	go func() {
+		errc <- CopyBuffer(rw2, rw1, bufferSize)
+	}()
+
+	if err := <-errc; err != nil && err != io.EOF {
+		return err
+	}
+
+	return nil
+}
+
+func CopyBuffer(dst io.Writer, src io.Reader, bufSize int) error {
+	buf := bufpool.Get(bufSize)
+	defer bufpool.Put(buf)
+
+	_, err := io.CopyBuffer(dst, src, *buf)
+	return err
+}
+
+```
+
 
diff --git a/02数据存取/1mysql/2执行计划.md b/02数据存取/1mysql/2执行计划.md
@@ -32,17 +32,17 @@ table: 查询的是哪个表
 
 partitions: 匹配的分区
 
-type: join 类型
+type: **访问类型​​**
 
 possible_keys: 此次查询中可能选用的索引
 
-key: 此次查询中确切使用到的索引.
+key: **此次查询中确切使用到的索引.**
 
 ref: 哪个字段或常数与 key 一起被使用
 
-rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
+rows: **显示此查询一共扫描了多少行. 这个是一个估计值.**
 
-filtered: 表示此查询条件所过滤的数据的百分比
+filtered: **表示此查询条件所过滤的数据的百分比,如10%）表示WHERE条件过滤性差，需优化索引。**
 
 extra: 额外的信息
 
@@ -80,9 +80,9 @@ extra: 额外的信息
 查询的行数,不准确,**可配合 `show status like "%innodb_rows%";`查看**
 
 ##### Extra
-- using index：出现这个说明mysql使用了覆盖索引，避免回表
-- using where：表示Mysql将对storage engine提取的结果进行过滤，过滤条件字段无索引
-- using temporary：这意味着mysql对查询结果进行排序的时候使用了一张临时表。
-- using filesort：这个说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。
+- using index：使用覆盖索引（查询列均在索引中，无需回表）。
+- using where：存储引擎返回数据后，还需在服务层过滤（WHERE条件未被索引完全覆盖）。
+- using temporary：需要创建临时表（常见于GROUP BY、ORDER BY未用索引）。
+- using filesort：需要额外排序（ORDER BY字段无索引）。
 - using join buffer (Block Nested Loop), using join buffer (Batched Key Access): 使用BNL或者BKA算法对join优化
 - Using index for group-by: 分组字段使用索引
diff --git a/02数据存取/1mysql/5事务和锁.md b/02数据存取/1mysql/5事务和锁.md
@@ -69,4 +69,5 @@ SELECT * FROM information_schema.INNODB_TRX;
 SELECT * FROM information_schema.INNODB_LOCKs;
 SELECT * FROM information_schema.INNODB_LOCK_waits;
 
-```
+```
+
diff --git a/02数据存取/1mysql/6优化.md b/02数据存取/1mysql/6优化.md
@@ -36,13 +36,16 @@ count(\*) :遍历整张表,不取值,直接加1,mysql优化器做的优化
 sort_buffer_size=2097152 #排序可使用的内存
 max_length_for_sort_data=1024 #每一行的数据长度
 ```
-```
+
+```shell
 排序过程:
 1. 初始化`sort_buffer`,确定排序字段,如果选取的字段小于`max_length_for_sort_data`的长度,就取出所有字段进行全字段排序,否则进行rowid排序
 2. 根据条件,选择满足条件的行的字段,放入`sort_buffer`
 3. 重复步骤2
 4. 对`sort_buffer`中数据按照排序字段进行排序,如果数据大于`sort_buffer_size`,需要使用外部排序,归并排序
 
+```
+
 ```sql
 #排序语句
 select city,name,age from t where city='杭州' order by name limit 1000  ;
@@ -134,8 +137,11 @@ revoke all privileges on *.* from 'ua'@'%';
 
 1. 如果明确知道只有一条结果返回，limit 1能够提高效率,明确告诉数据库，让它主动停止游标移动
 2. 避免全表扫描
-3. 只返回需要的列，能够大大的节省数据传输量，与数据库的内存使用量
-4. 项目上线前,将慢查询日志打开,并把long_query_time=0,查看所有的日志
+3. 仅查询所需字段
+4. 小表驱动大表，确保关联字段有索引​​
+5. 打开慢日志
+6. 子查询优化​，用JOIN替代IN/EXISTS
+7. 避免长事务
 
 #### group by 的优化
 1. 如果对group by 语句的结果没排序要求,加上order by null
@@ -158,4 +164,16 @@ revoke all privileges on *.* from 'ua'@'%';
 1. 行记录,无法存储数据结构 (redis)
 2. schema 扩展很不方便,比如数据多的情况下,添加列,锁表 (mongodb)
 3. 大数据场景下,i/o高 (hbase)
-4. 全文检索弱 (elasticsearch)
+4. 全文检索弱 (elasticsearch)
+
+## 数据库设计范式
+
+| 范式    | 规则与目标                                                                 | 解决的问题                   | 示例                                                                 |
+|---------|--------------------------------------------------------------------------|------------------------------|----------------------------------------------------------------------|
+| **1NF** | 字段原子性，每列不可再分，有唯一主键                                       | 消除重复组和非原子值           | 拆分多值字段（如将 `Phone: 123,456` 拆分为多行）                      |
+| **2NF** | 满足1NF，消除非主键字段对复合主键的部分依赖                                 | 部分依赖导致的数据冗余         | 拆分表（如订单表与产品表分离）                                        |
+| **3NF** | 满足2NF，消除非主键字段间的传递依赖                                         | 传递依赖导致的数据冗余         | 拆分表（如用户表与地址表分离）                                        |
+| **BCNF**| 满足3NF，消除主键属性对非候选键的依赖                                       | 主键属性与非候选键的依赖异常   | 拆分表（如导师-学生关系与研究方向分离）                               |
+| **4NF** | 满足BCNF，消除多值依赖                                                     | 多值字段导致的数据冗余         | 拆分多值字段为独立表（如兴趣和技能拆分为多张表）                      |
+| **5NF** | 满足4NF，消除连接依赖（表可无损分解为更小表）                               | 复杂关联导致的信息丢失风险     | 分解三元关系为多个二元表（如供应商-产品-项目拆分为三张表）            |
+| **实践**| 通常设计到3NF或BCNF；需权衡范式与查询性能，必要时反规范化（Denormalization） | 平衡数据一致性与查询效率       | OLTP系统使用3NF，OLAP系统采用星型/雪花模型（反规范化）                |
diff --git a/07分布式系统/12熔断.md b/07分布式系统/12熔断.md
@@ -0,0 +1,6 @@
+# 熔断
+
+## ​目标​​
+当依赖服务异常（如超时、错误率上升）时，快速失败并避免级联故障。
+## ​​场景​​
+微服务调用、第三方API依赖、防止服务雪崩。
diff --git a/07分布式系统/9服务发现.md b/07分布式系统/9服务发现.md
@@ -0,0 +1,12 @@
+# 服务发现
+
+| 维度         | etcd                                | Nacos                               | Consul                              |
+|--------------|-------------------------------------|-------------------------------------|-------------------------------------|
+| 核心定位     | 分布式键值存储（基础设施层）        | 服务发现与配置管理（应用层）        | 服务发现与多数据中心治理            |
+| 一致性模型   | 强一致性（Raft）                    | AP/CP 模式可选                      | 强一致性（Raft）                    |
+| 数据模型     | 键值对                              | 服务、配置、元数据                  | 键值对、服务元数据                  |
+| 主要功能     | 键值存储、集群协调                  | 服务注册、动态配置、健康检查        | 服务发现、健康检查、多数据中心       |
+| 适用场景     | Kubernetes 核心存储、分布式锁       | 微服务配置中心、服务治理            | 多云环境服务治理、跨集群协调         |
+| 管理界面     | 无原生 UI（依赖 CLI 或第三方工具）  | 提供 Web 控制台                     | 提供 Web 控制台                     |
+| 生态集成     | 深度集成 Kubernetes                 | Spring Cloud、Dubbo、K8s            | HashiCorp 生态（如 Vault、Nomad）   |
+| 学习成本     | 低（功能单一）                      | 中（功能丰富）                      | 中（多模块组合）                    |
diff --git a/13区块链/contract/eth.md b/13区块链/contract/eth.md
@@ -79,7 +79,7 @@ The Graph可以让我们部署一个Graph查询服务，如何定义表结构以
 - 重入攻击
   - 防止重入攻击的方法是一定要在校验通过后立刻更新数据，不要在校验-更新中插入任何可能执行外部代码的逻辑。
   - 
-  ```solidity
+```solidity
   // 先回调再更新的方式会导致重入攻击，即如果callback()调用了外部合约，外部合约回调transfer()，会导致重复转账
   function transfer(address recipient, uint256 amount) public returns (bool) {
     require(recipient != address(0), "ERC20: transfer to the zero address");
@@ -93,4 +93,43 @@ The Graph可以让我们部署一个Graph查询服务，如何定义表结构以
     emit Transfer(sender, recipient, amount);
     return true;
     }
- ```
+```
+
+## EVM
+是以太坊网络中运行智能合约的全局分布式计算机，负责执行合约字节码并更新区块链状态。
+### 核心特点包括:
+- ​确定性​​：相同输入下执行结果唯一
+- ​隔离性​​：运行在沙盒环境中，无法直接访问外部系统。
+- ​燃料（Gas）驱动​​：每步操作消耗 Gas，防止资源滥用。
+
+### 核心组件
+
+| **组件**             | **功能**                                                           |
+| -------------------- | ------------------------------------------------------------------ |
+| **堆栈（Stack）**    | 保存临时数据（深度为 1024，每个槽位 256 位），用于算术和逻辑运算。 |
+| **内存（Memory）**   | 临时数据存储（按字节寻址，读写成本低于存储）。                     |
+| **存储（Storage）**  | 永久性键值存储（每个合约独立，读写成本高）。                       |
+| **程序计数器（PC）** | 指向当前执行的字节码位置。                                         |
+| **Gas 计数器**       | 跟踪剩余 Gas，耗尽则终止执行并回滚状态。                           |
+
+---
+
+### 数据模型
+- **256 位字长**：所有操作基于 256 位数据（兼容以太坊的 32 字节地址和哈希）。  
+- **大端序（Big-Endian）**：数据高位存储在低地址。
+
+### EVM 执行流程
+- 交易触发
+  - **用户发起交易**：调用合约函数或转账 ETH。  
+  - **交易包含**：目标地址、输入数据、Gas 限制、Gas 价格等。
+- 字节码加载
+  - **合约部署**：合约的 Solidity/Vyper 代码编译为 EVM 字节码（如 `606060...`）。  
+  - **执行上下文**：创建执行环境（包括账户状态、Gas 余额等）。
+- 指令执行
+  - **操作码（Opcode）**：EVM 的底层指令集（如 `PUSH1`, `ADD`, `SSTORE`）。  
+  - **逐条解析**：从字节码中读取操作码，更新堆栈、内存或存储。  
+- Gas 消耗
+  - ​每步操作消耗 Gas​​：例如 ADD 消耗 3 Gas，SSTORE 首次写入消耗 20,000 Gas。
+- 状态更新
+
+
diff --git a/13区块链/contract/合约示例.md b/13区块链/contract/合约示例.md
diff --git a/17基础设施/5PKI.md b/17基础设施/5PKI.md
diff --git a/18安全与加密/1CSRF.md b/18安全与加密/1CSRF.md

-Original file line number
+Diff line change
@@ @@ -0,0 +1,6 @@ @@
 +# 熔断
++
 +## 目标
 +当依赖服务异常（如超时、错误率上升）时，快速失败并避免级联故障。
 +## 场景
 +微服务调用、第三方API依赖、防止服务雪崩。