# 设备和驱动程序
## Everything is a File

#### 文件：有 “名字” 的数据对象

- 字节流 (终端，random)
- 字节序列 (普通文件)

#### 文件描述符

- **指向操作系统对象的 “指针”**
    - Everything is a file
    - 通过指针可以访问 “一切”
- 对象的访问都需要指针
    - open, close, read/write (解引用), lseek (指针内赋值/运算), dup (指针间赋值)

## I/O 设备

I/O 设备 = **一个能与 CPU 交换数据的接口/控制器**

- 就是 “几组约定好功能的线” (寄存器)
    - 通过握手信号从线上读出/写入数据
- 给寄存器 “赋予” 一个内存地址 (Address Decoder)
    - CPU 可以直接使用指令 (in/out/MMIO) 和设备交换数据
    - 是的，就这么简单

## 总线
提供设备的**虚拟化**：**注册**和**转发**
- 把收到的地址 (总线地址) 和数据转发到相应的设备上
- 例子: port I/O 的端口就是总线上的地址
    - IBM PC 的 CPU 其实只看到这一个 I/O 设备

#### 今天获得 “CPU 直连” 的标准设备

- 接口
    - 75W 供电
        - 所以我们需要 6-pin, 8-pin 的额外供电
- 数据传输
    - PCIe 6.0 x16 带宽达到 128GB/s
        - 于是我们有了 800Gbps 的网卡 😂
    - 总线自带 DMA (专门执行 memcpy 的处理器)
- 中断管理
    - 将设备中断转发到操作系统 (Message-signaled Interrupts)

## 应用程序访问设备
一个设备会被多个程序使用，而设备的使用是基于上面的**寄存器**进行交互，如果不加以管理是非常混乱的。

通过**操作系统虚拟化设备** => **Everything is a File**

源自于***Everything is a File***，设备被虚拟化为Unix上/dev/中的文件，而这些文件就是设备上的寄存器

**驱动程序（Drive）**，把系统调用 “翻译” 成与设备能听懂的数据（就是一段普通的内核代码）

### 配置设备
设备交互的复杂不在于如何使用，而在于配置设备

设备不仅仅是数据，还有**配置**
### 两种实现方法

- 控制作为数据流的一部分 (ANSI Escape Code)
- 提供一个新的接口 (request-response)

# 存储设备原理

一个能**反复改写的状态**
- 寻址+电路改写 

经过这么多存储媒介的更迭，但是**存储设备的抽象**缺没有变更
#### 从1Bit到1TB
- **寻址能力**的代价
	- 磁盘：位置划分 + 扇区头
	- 电路：行 (字线) 和列 (位线) 选通信号
	    这些都会消耗额外的资源 (面积)

#### 解决方法：按块访问
- “一块” 可以共享 metadata
    - 物理分割、Erase 信号、纠错码……
    - 磁盘是 `struct block disk[NUM_BLOCKS]`
        - Block 是读/写的最小单位
        - **Block devices 块设备** (ls -l /dev/sd*)

#### 透明抽象的代价

- 不经意间的读/写放大 (read/write amplifications)
- 存储设备在实际执行读写操作时，处理的数据量超过用户实际请求的数据量
    - 随机读/写一个 byte，都会导致大量数据传输
    - 文件系统的实现应该能够**感知** “块” 的概念

### Linux Bio

Linux中通过**Linux BIO**系统实现**块设备管理**
- 上层 (进程、文件系统……) 可以任意提交请求
- 下层 (Bio + Driver) 负责调度
![[assets/持久化/file-20250606140816646.png]]

## 最后的版本答案——电存储 
![[assets/持久化/file-20250606140442119.png]]


# 文件系统API

## 存储设备的抽象

磁盘 = 块（字节）序列

文件，虚拟的磁盘
怎么管理文件？
- 树状分层索引：信息的局部性
- 路径  => 结构化查询 =>  智能检索

### 链接


- 硬（Hard）链接
	- 同一个文件可以被重复“引用”，链接
- 软（Symbolic）连接
	- **“ 跳转提示 ”**

### Linux系统文件元数据

- Type：d (directory), l (link), p (pipe), c (char), b (block)
- Mode（权限）rwx (user, group, other)
	- 例子：0o755 = rwx (111) r-x (101) r-x (101)
- Links（硬连接）：引用计数 (硬链接，包括目录)
 
- Extended Attributes (xattr) 更多的元数据
	- 每个文件可以维护一个任意的 key-value dictionary
	```c
	ssize_t fgetxattr(
		int fd,
		const char *name, 
		void value[.size], 
		size_t size
	);
		 
	int fsetxattr(
		int fd, 
		const char *name, 
		const void value[.size], 
		size_t size, 
		int flags
	);
	```

### 联合挂载
将硬盘设备虚拟化，得到了文件系统
将文件目录虚拟化，得到了**容器、快照**
在后面关于容器的课程会详细讨论......

---
# 文件系统实现

**文件系统实现**就是在**块设备**（硬盘）上实现一个**数据结构**，来对数据进行管理

通过文件系统，映射到磁盘上对应的数据，从而进行管理

## LVM
传统意义上，磁盘的虚拟化 => 文件系统
现在通常是，使用LVM（Logical Volume Manager，逻辑卷管理器）
![[assets/持久化/file-20250625141445505.png]]
LVM是一种块设备虚拟化技术，它允许操作系统将多个物理存储设备组合成一个或多个逻辑卷，从而提供更灵活和高效的存储管理。
LVM的架构：
1. 物理层
2. 物理卷
3. 卷组
4. 逻辑卷
5. 文件系统

- 物理硬盘首先被Linux挂载为`/dev/sda`, `/dev/sdb`，将物理硬盘变为**Linux上可用的资源**
- 然后LVM将挂载的硬盘，纳入并初始化设备为物理卷，也就是LVM系统中的数据结构
- **卷组（VG）** 将多个物理卷（PV）组合成一个统一的存储资源池，作为LVM的核心管理单元
- 基于卷组的资源，LVM构建出**逻辑设备**——**逻辑卷**，并将逻辑卷挂载到Linux上，作为一个标准的块设备`/dev/vg_name/lv_name`

*不过这部分内容不是这里的重点，这里主要探讨如何实现**文件系统***

## FAT
文件是由多个块设备中的块组成的，多个块按一定的顺序排列，就组成的文件

于是乎文件在块设备的存储问题，变成了**如何管理块设备中的块关系**

- 两种设计
	- 在每个数据块后放置指针
		- 数据大小不规则，要读文件最后一位就得全读一遍（链表）
	- ==将指针集中存放在文件系统的某个区域==
		- 局部性好，随机读取更佳
		- 索引损坏会导致全部数据丢死

- **FAT** File Allocation Table: 集中保存所有指针

### 目录树
目录就是个普通文件

- 但在 metadata 里标记一下 (mode = directory)
    - 操作系统把数据理解成 struct dirent[]
    - Quiz: 为什么不把元数据 (大小、文件名、……) 保存在文件的头部？
- DOS: “8 + 3” 文件名 “AUTOEXEC.BAT”
    - Linux: /etc/xdg/autostart/
    - Windows: shell:startup

### inode

联合数据结构 ext2

持久化

多线程程序的状态机模型
- **新增的特殊系统调用**：spawn()
	- 新增一个"状态机"
	- 独立的栈
	- 共享全局变量

>[!hint] 
>- 并发
>	- 逻辑上的"同时执行"
>	- 通过操作系统或者运行库(java)模拟的"轮流执行"
>- 并行
>	- 真正意义上的"同时执行"
>	- **共享内存**的多个处理器

# 并发编程的代价
## 1. 非确定性
不同时读写，导致数据覆盖

## 2.编译器优化中的Determinism(确定性)
虚拟化给了进程**Determinism**：
- 除了系统调用外，没有东西能干涉程序的状态
因此：
- 编译器：按照"syscall"优化程序代码
	只要保证在"syscall"层面是一样的,可以随便改变语句
==**但是，编译器的优化是基于Determinism的**==
失去了Determinism编译器优化后的程序，在多线程环境下无法正确运行
- 解决方案
	1. 插入“不可优化”的代码块
	2. 标记变量为“不可优化”
	3. ==《操作系统》课程的推荐方法：不要玩火🔥==

## 3.宽松内存模型
为了更快的读取速度性能 
- 数据先写入CPU的cache，再同步给其他处理器
- 允许读取到旧值

- 现代处理器的“乱序执行”

# 解决问题：互斥
对于解决并发1+1 -> **阻止同时的sum++**
**互斥**
- 锁?
- 状态迁移
- *实现资源独享*
- 并发变回单线

## 锁——互斥的实现
- 悲观锁&乐观锁
	- 程序变快1/k
	- 并行总是能实现的 , 虽然不能**并发** , 但是当数据量够大时**大规模并行**总能提升性能

| **特征**    | **乐观锁**            | **悲观锁**            |
| --------- | ------------------ | ------------------ |
| **冲突假设**  | 假设冲突很少             | 假设冲突频繁             |
| **加锁时机**  | ==操作前不加锁，提交时检查冲突== | ==操作前立即加锁，阻塞其他线程== |
| **性能**    | 无锁操作，冲突少时性能高       | 有锁操作，冲突多时性能稳定      |
| **实现复杂度** | 需要版本号、CAS 等机制      | 依赖操作系统或数据库的锁机制     |
| **典型场景**  | 高并发、低冲突（如数据库更新）    | 低并发、高冲突（如银行账户操作）   |

**永远不要用不要用共享内存做互斥**
	数据有传播延迟，CPU核心有自己的内存（Cache），核心之间的内存共享做**懒处理**
	编译器会优化
## 实现互斥：硬件
电脑是人造的，BYD我是土皇帝

把锁的层级提升到硬件，**Atomos原子指令**
通过Atomos，在硬件层面上实现一个类似下面锁代码：
~~~c
void lock() {
retry: 
	if (can_go == ![✅]) { 
		can_go = ![❌]; // then function returns 
	} else { 
		goto retry;
	} 
} 
void unlock() {
	can_go = ![✅]; 
	}
~~~
==而对于那些使用原子指令实现的并发层序，都是硬件基于上面实现的锁==

>[!example] 各个CPU架构上的Atomos
>- 一个 “不被打断” 的 load + 计算 + store
 >   - x86: Bus Lock (locked instruction)
 >   - RISC-V: LR/SC & A 扩展
 >       - 来自 MIPS: Load-Linked/Store-Conditional >(LL/SC)
 >   - arm: ldxr/stxr, stadd (store add) 指令


对于每一个临界变量都有自己的一把锁，自旋锁



## 提升性能
- ### 性能问题——Scalability 可拓展性
	- 自旋锁的Scalability，一万个线程 >> CPU物理线程
		- “一核有难，八核围观”
			- 只有带锁的线程干活，其他无锁的线程都在空转
		- 应用程序不能关中断
			- 拿着锁的线程，被操作系统中断，切换到其他线程
			- 但是切换到的线程进行计算需要锁，拿不到锁导致空转

- ### 解决——锁的控制交由操作系统控制
	硬件提供机制解决问题，操作系统再实现程序提高性能
	- 系统调用（SYSCALL_acquire / SYSCALL_release）
		- `SYSCALL_acquire(&lk)`
		    - **成功**：线程获得锁，直接返回。
		    - **失败**：将线程状态标记为“不可执行”（挂起），并切换到其他线程（上下文切换）。
		- `SYSCALL_release(&lk)`
		    - 释放锁后，检查等待队列中是否有线程在等待该锁。
		    - 若有，唤醒其中一个线程（如FIFO策略），使其进入“可运行”状态。
	- 实际使用中`pthread_mutex_t lock`最通用且性能平衡

# 解决问题：同步
互斥实现了**原子性**，保证了A->B OR B ->A
但是由于线程的先后顺序不确定，A->B的**稳定性**还没有保障

>[!tip] 理解并发的方法
>- 线程 ->我们自己
>- 共享内存 ->物理空间 

## 同步？
- 什么是同步？
	两个及以上的量，随时间变化，在这个过程中保持**一定的相对关系**
	- 多线程同步：多个事件、进程或系统在时间上时间协调一致，确保按**预定顺序**或**同时**执行

对于互斥来说，只能做到**分开**
***
## 理解同步
***理解同步：什么是事件（代码的执行）、什么是顺序***


- **同步点：** 一个确定的状态，从而实现**并发控制**
- **控制：** 将发散的并发程序状态**收束**

## 实现同步
- 老方法，古法同步（
	- 不断循环观测起跑Flag
	- 也是老问题，性能差

-  性能优化

	- 每一次有线程完成了，就唤醒一下完成了的线程看看人齐了没有


### 经典永流传——生产者-消费者问题   
任何同步问题都需要**锁🔒**
**==条件变量总是和一个互斥锁联合使用==**
```
mutex_lock(🔒);
while (!cond) {  // cond 可以是任意的计算
    cond_wait(&cv, 🔒);
}
assert(cond);    // 此时 cond 成立且持有锁 lk
mutex_unlock(🔒);
```

```
// 注意锁的使用
mutex_lock(🔒);
cond = true;
cond_broadcast(&cv); // 唤醒所有可能继续的线程
mutex_unlock(🔒);

```

万能的同步方法：条件变量
- 保证了程序状态机的确定性，收束到我指定的状态

而使用条件变量，只需要回答一个问题：
	”什么时候执行方法？“

- **Happens-Before**
	- 也是一次生产一次消费
	- 改造单线程程序实现并行的关键
	- 有向无环图，Dependence（上一轮的结果交给下一轮用，同一轮的可以并行）

### 程序并行改造，同步——实现任意计算图
- 节点想要执行，所有的依赖节点已经完成（可以用一把大锁同步一轮）

- 实现一个任务的调度器Scheduler
	- 拿着所有的锁，控制所有的workers
	- Scheduler可以知道CPU的拥挤度
	- 管理一个任务队列（不是线程队列），队列内部实现一个拓扑排序。然后合理地（根据拓扑关系）在不同的Worker线程上，排队任务（同个Worker排队多个任务，轮次不同的任务可能要等待上一轮的结果）

---
# 同步：信号量
实现同步->Happens-Before->条件变量
实现互斥->互斥锁
>[!question] 互斥锁实现同步？
>我们通过mutex互斥锁，实现线程之间的互斥运行
>实际上在这些互斥的线程中，也存在一种**Happens-Before**的关系（A to B / B to A）
>
>而同步的实现是基于各个线程**Happens-Before**关系
>因此，我们是否能借助**Mutex**来实现一个**更高效的同步**呢——**信号量**

## 互斥锁的拓展——信号量🚨
对上面的想法进行抽象，本质上是Release-Acquire实现了Happens-Before
- Acquire = 等待信号🚨
- Release = 发出信号🚨

信号🚨在这里可以视为一种**资源许可**
- 共享的资源但是凭**票（🚨）** 进入

## 信号量的局限性
- Faker！信号量 VS 条件变量，你们知道吗？
	- **信号量**
		- 干净！优雅！完美！（并非完全）
		- 不太好表达**二选一**
		- `count`不总是能很好地**代表**同步条件
	- **条件变量**
		- 万能：能实现**任何**（~~anything~！~~）的同步条件
		- 丑陋：代码总感里有什么脏东西 (spin loop)

- 更复杂的同步问题——复杂的条件变量？

> [!example] 哲♂学家吃饭
> ![[file-20250513195719748.png]]
>哲♂学家们一起吃饭，他们有时会思考有时会吃饭。
>吃饭的时候需要举起他们左右手的叉子，只有举起左右手的叉子后，他们才会开始吃饭。
>- 问题：吃了很久很久后，**于是乎在某一个时刻**，所有哲学家同时**都举起左手的叉子**，大家就都等待右手的叉子

并非完美，信号量不总是优雅
- **数值型资源不能总是很好地表达同步条件**

- 引入调度者，统一管理全部资源（叉子） 
	- **想要通过局部交互来控制全局是非常困难的事情**
	- 作为拥有全部资源的调度者，获取到更多的信息，从而不止局限在附近的叉子，而是能全局地看待，更好地分配叉子（哲学家申请要叉子，调度者根据情况分配）

---

# 并发Bugs
- T1线程改变了数据，干扰了T2的运行
- 函数式编程，代码中的函数像是数学公式一样，就不会产生不确定性 

并发编程困难的本质
- 人类是Sequential的生物，我们只能用Sequential的方式去理解并发（原子性操作）
 
## What & From 
### 源头
- **Data Race 数据竞争**
	**不同的线程**==同时==访问**同一内存**，且**至少有一个是写**

- **Atomicity Violation 原子性违反**
	一个**操作序列（多个相关操作）** 在执行过程中被其他线程中断，导致部分操作完成而另一部分未完成，**破坏整体逻辑一致性**
	- ~~吃饭的时候站起来，被偷偷拿掉凳子了（~~

- **Order Violation 顺序违反**
	事情未按预定的顺序发生![[file-20250516185226498.png]]

### 问题
- **Deadlock 死锁** -> 数据竞争
	- 四个必要条件
  > [!PDF|yellow] [[操作系统导论 ( etc.) (Z-Library).pdf#page=294&selection=10,0,24,20&color=yellow|操作系统导论 ( etc.) (Z-Library), p.294]]
  >   > 		- 互斥：线程对于需要的资源进行互斥的访问（例如一个线程抢到锁）。
  >   > 		- 持有并等待：线程持有了资源（例如已将持有的锁），同时又在等待其他资源（例如，需要获得的锁）。
  >   > 		- 非抢占：线程获得的资源（例如锁），不能被抢占。
  >   > 		- 循环等待：线程之间存在一个环路，环路上每个线程都额外持有一个资源，而这个资源又是下一个线程要申请的。如果这 4 个条件的任何一个没有满足，死锁就不会产生
    > 

- **非死锁问题** -> 原子性/顺序违反
## 解决并发BUG
- **Lock Ordering**
	- 任意时刻系统中的锁都是有限的
	- 给所有锁编号 (Lock Ordering)
		- 严格按照从小到大的顺序获得锁
		- 这个也容易检查，通过LockDoc（打印记录Lock）

-  原子操作

>[!check] 用好现代的程序工具
>开发者社区已经为这些MillionDollorsMistake尽可能地提供解决方案

---

# 并发编程，Let's Talking About Usage

## 并发编程的核心抽象
- **计算图模型**
	- 在图中的节点上计算，计算结果彼此之间相互依赖（数字电路模拟、深度神经网络、最长公共子序列）
	- 计算图可能是**动态**的
- **实现计算图**
	要实现计算图模型，就需要实现**同步条件**（$u$的所有Predecessors都完成）
	- **条件变量**
	- **信号量**

然而，在计算图的实现上，原子性、信号量和条件变量虽然提供了基础的同步条件功能，**但这并不是计算图优雅的实现方式**（好比用汇编代码做开发......）

在实现这些**同步条件**的时候，我们代码中往往会充斥许多的**干扰代码**，而往往我们会在这里犯错（比如上错锁，或者忘记上锁）![[assets/并发编程/file-20250527131756842.png]]

然而，在长期的编程实践中，程序员们总结出了**一定的规律**，能为我们提供一些**封装的方法功能**实现计算图

## 高性能计算中的并发编程
Embarrassingly parallel（易并行）的计算（物理计算）

通常计算图容易静态切分


## Web中的并发编程
Web2.0的到来，带来了并发的需求
- **event-based concurrency（动态计算图）**
	- 禁止任何计算节点并行
    - 允许网络请求、sleep 在后台执行
        - 执行完后产生一个新的**事件** (计算节点)
    - 假设网络访问占大部分时间；浏览器内计算只是小部分
    - **事件可以在浏览器里看到！**

- Callback Hell
- Promise

- “框架” 是驱动技术发展的原动力
- 我们需要**好的抽象**来表达人类世界中的需求
    - **简单可靠**，聚集大量行业开发者
        - AI 也许是这里的 “开发者”
    - **灵活通用**，构造各种应用程序

## 数据中心的并发编程
不同于高性能计算，以海量分布式数据（存储）为中心
- 实时的 “小数据处理”
    - 内容分发、用户认证、视频直播、弹幕……
- 离线的 “大数据处理”
    - 内容索引、数据挖掘……


- **数据中心里的并发问题**
	- **高吞吐 (QPS) & 低延迟的事件处理**
		- 处理事件可能需要读写持久存储或请求网络上的服务
		    - 延迟不确定
		- 线程维护和上下文切换都会带来开销
	- **假设有数千/数万个请求同时到达服务器……**
		- “Denial of Service, DoS”
		    - 全国的小爱音箱在小米汽车发布会上同步瘫痪

- Challenge: 高可靠、低延迟的多副本分布式存储和计算
	- **数据保持一致 (Consistency)**
	- **服务时刻可用 (Availability)**
	- **容忍机器离线 (Partition tolerance)**
	不可兼得的不可能三角

## 协程
**和线程概念相同**

- 进程内独立堆栈、共享内存的**状态机**
	- 在同一个操作系统线程中执行
    - 可以由程序控制调度
    - 除了内存，不占用额外操作系统资源
- 但 “一直执行”，直到 yield() 主动放弃处理器
    - yield() 是函数调用
        - 只需保存/恢复 non-volatile 的寄存器
        - (线程切换需要保存/恢复全部寄存器)
    - 但 sleep (I/O) 时，所有协程都 “卡住了”
        - 失去了并行

### Go 和 Goroutine

**小孩子才做选择，多处理器并行和轻量级并发我全都要！**

- Goroutine: 概念上是线程，实现是线程和协程的混合体

**Goroutine 实现**
- 每个 CPU 上有一个 Go Worker Thread (协程调度器)
- 协程执行 blocking API (sleep, read)
    - 偷偷调用 non-blocking 的版本
    - 成功 → 立即继续执行
    - 失败 → 立即 yield 到另一个需要 CPU 的 goroutine
        - 完全可以在单个服务器上启动 1,000,000 个 goroutine 共享处理器算力

## CPU内的并行编程 
什么是CPU？
	无情的执行指令的机器（并非）

### 实际的CPU（Instruction-Level Parallelism）

- CPU其实一直在**并行编程**
	指令的执行也是一种**计算图**，对于没有数据依赖多条指令，CPU可以从PipeLine上**预读**多条指令，然后构建一个**并行的计算图**执行

- 每个 CPU 核心都是一个**编译器**
	- 动态 (运行时) 数据流分析和指令调度
    - 服务器 CPU 上可能**同时有上千条指令在执行**

- 这意味着什么？——用数字电路实现一个**编译器**
	- 能效&性能 -> 选择了性能，带来的巨量的发热（浪费了很多电路，进行很多的门电路翻转）

>[!example] Dark Silicon “暗硅时代”
>- P=C⋅V2⋅f
>- “功耗墙”：纵使有更大的电路，热功耗限制了性能上限

### 面对功耗墙
$$P=C⋅V^2⋅f$$

- 如何在降低 VV 和 ff 的同时，用面积换性能？

#### 1. 让一条指令能处理更多的数据
- **SIMD (Single Instruction, Multiple Data)**
    - “一条指令” 浪费的能量大致是定数
    - 处理的数据越多，浪费越少

#### 2. 用更多更简单的处理器
- 多处理器系统、异构多处理器
    - 同等面积，处理器越简单，数量越多
    - 大小核，小核的能效比更高
		- 更小、更简单的核心——甚至可以不需要有CPU指令集的计算能力
		- “领域专用加速器”
			- ISP: Image Signal Processing (手机相机)
			- GPU: Graphics Processing Unit (图形渲染)
			- DPU: Data Processing Unit (网络/数据处理)

>[!summary] 向量指令
>向量指令（Vector Instruction）是一种**单指令多数据**（Single Instruction, Multiple Data, SIMD）的指令形式，它通过一条指令同时对**多个数据元素**进行相同的操作，从而显著提升数据处理效率。这种指令集设计主要用于**并行计算**场景，尤其适合需要处理大规模数据的高性能计算、多媒体处理和机器学习等领域。


### GPU：Need More Threads

>[!info] 图形渲染原理——GPU的由来
>计算屏幕上每个像素点要展示的RGB Value（光照的变化等......）
>![[assets/并发编程/file-20250530163954871.png]]
>而对于屏幕上的每个像素点（也就是Shader函数）都是可以并行的，我们就需要大量的线程实现并行（2,073,600个线程）

- SIMT（Single instruction, multiple **threads**）
  ——GPU上的并行
	**单指令多线程**：多个Cores共享一个PC，实现所有线程同步执行相同指令

- 线程发散
	
	
	- 分支对于GPU执行指令的损耗是很大的，但是多线程重复指令GPU很擅长
	- 

>[!summary] 线程发散
>**线程发散（Thread Divergence）** 是指同一线程束（Warp/Wavefront）中的线程因条件分支（如`if-else`）进入不同的执行路径，导致GPU无法并行执行所有线程，从而降低效率的现象
>
>- CPU为了执行业务逻辑，要执行、加载很多**离散的代码**。
>  因此CPU更擅长处理线程发散，而对于要同时执行大量的相同指令，优化是很差的
>- 而线程发散对于GPU执行指令的损耗是很大的，但是多线程重复指令GPU很擅长
>
>因此，当你的程序对内存的访问，符合正确的模式时，GPU才能发挥最大的带宽



并发编程


# 概念

JVM 全称是 Java Virtual Machine，中文译名 Java虚拟机。
JVM 本质上是一个运行在计算机上的**程序**，他的职责是运**行Java字节码文件**。

## 三大功能
解释运行、内存管理和即时编译——JVM：我今天运行起来只为三件事（
- 解释运行![[assets/JVM/file-20250508211934315.png]]
- 内存管理
	- ~~Java学长这招可太狠了~~，内存的分配和回收都交给JVM来处理，对程序员编写代码友好（jyy老师曾经说程序员是不可信的......因为会犯错）
- 即时编译
	对热点代码进行优化，提升执行效率。即时编译可以说是提升Java程序性能最核心的手段
	
	- Why？——优点
		- 实现跨平台
		- 提高性能
			- 热点代码——虚拟机是智能的，在运行的时候会发现某个方法被高频调用，就会对这段代码进行优化（在此处不做过多深入）
				- 优化——代码逻辑结构优化，更适合机器运行
				- 缓存——缓存解释过代码的字节码

## JVM组成
![[assets/JVM/file-20250508215423528.png]]
- 类加载器系统
	- 核心组件类加载器，负责将字节码文件(.class)中的内容加载到内存中
- 运行时数据区
	- JVM管理的内存，创建出来的对象、类的信息等等内容都会放在这块区域中
- 执行引擎
	- 解释器
		- 将字节码指令解释成机器码
	- 即时编译器（JIT Compiler）
		- 将热点代码（高频执行的代码）编译为本地机器码，提升性能
	- 垃圾回收器
		- 回收不再使用的对象

- 本地方法接口（JNI, Java Native Interface）
	- 调用本地使用C/C++编译好的方法，本地方法在Java中声明时，都会带上native关键字

## JMM 内存模型
JMM（Java Memory Model），官方名称为**运行时数据区域**。

JVM在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。这里我们根据线程是否共享，可以简单地分为**主内存和工作内存**。![[assets/JVM/file-20250721162725868.png]]

- 主内存
	- 所有线程共享的区域，包含了所有共享变量、类信息、实例对象等，也就是运行时数据区域中的堆和方法区的数据。
- 工作内存
	- 每个线程在执行时的私有空间，包含了局部变量表、操作数栈等，也就是运行时数据区域中的程序计数器和栈的数据。

从上面主内存和工作内存的区分，当我们将JVM视作一个操作系统，两个内存。我们可以认为一个是程序里面的内存，负责运行程序中的变量、方法等数据；另外一个是我们计算机的内存，负责在我们电脑开机运行过程中数据的管理

### 工作内存
工作内存，也就是线程私有的内存，分为三个区域：
- 程序计数器
- 虚拟机栈
- 本地方法栈

#### 程序计数器
功能类似于CPU的PC计数器，但是在JVM中不同于CPU中的PC计数器，JVM中的程序计数器是**每个线程独立拥有一个的**。

如此一来，各线程之间计数器互不影响，独立存储，便于线程切换后的恢复

程序计数器主要有两个作用：
- 字节码解释器通过改变程序计数器来依次**读取指令** *（如：顺序执行、选择、循环、异常处理）*
- 多线程下，记录当前线程执行的位置

#### 虚拟机栈
Java 虚拟机栈（后文简称栈）也是线程私有的，它的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。

回顾操作系统角度的JVM，虚拟机栈在这里作为程序（工作内存）的内部栈。一个程序在运行过程中是会调用很多方法，然后在各个方法之间进入返回，而栈的结构就类似方法之间的进出。

![[assets/JVM/file-20250721164540439.png]]
栈的每次压入弹出，就相当于我们进入方法、计算处理，然后返回结果。而在方法中又有许多信息需要存储和读取，所以栈中又有许多栈帧，每个栈帧中都拥有：
- 局部变量表
	- **局部变量表** 主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。
- 操作数栈
	- 主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。
- 动态链接
	- 主要服务一个方法需要调用其他方法的场景。Class 文件的常量池里保存有大量的符号引用比如方法引用的符号引用。当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用，这个过程也被称为 **动态连接** 。
- 方法返回地址

#### 本地方法栈
和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

### 主内存
主内存是所有线程共享的内存

首先要问为什么为什么登录用『redis+session』，首先就得问他爹『为什么登录要用Session』！问他爹为什么用Session就得问他爷爷『为什么要有Session和Coookie』！问为什么要有他两就得问他曾爷爷『HTTP协议中的无状态补充——Session』！

为什么为什么为什么？！？！本文章今天就来抛砖引玉，串一串这几个东西：Redis+JWT、Session&Cookie、HTTP的无状态协议。究竟是道德的沦丧？还是人性的堕落？今夜本文为你一究到底！
用Token替代Session

## 问题
刚才我们已经初略提出了我们问题的雏形，我们简单梳理一下我们的问题。

为什么我们要使用『redis+session登录验证』？
因为Session受限与一个服务器进程

为什么我们要用『Session登录验证』？
因为我们要实现用户登录状态的保持，避免重复登录

为什么我们要『使用Session来实现状态保持』？
因为Session&Cookie实现了HTTP会话状态管理。补充了HTTP无连接特性下，状态保持的欠缺

# 为什么我们要『使用Session来实现状态保持』？
首先来回答第一个问题：为什么我们要『使用Session来实现状态保持』？

有因必有果，存在即合理。在计算机的世界中，每一项技术都是由人来选择、使用的，而这里面必然由它被选中的理由，而Session也如此。

### 背景
遥想天地之初，互联网的世界尚且还是一片荒漠，计算机处理能力低下，存储容量小，网速很慢。万维网的开宗老祖——蒂姆·伯纳斯·李（Tim Berners-Lee），在 1989 年，他发表了一篇论文，提出了在互联网上构建超链接文档系统的构想，在这篇论文里他确立了三项关键技术：

- URI：统一资源标识符，作为互联网上资源的唯一标识
- HTML：超文本标记语言，描述超文本文档
- HTTP：超文本传输协议，用来传输超文本

此文一出，顿觉Web天地宽，开天辟地了我们当今Web世界的技术。由于在早期的互联网中，大多数资源都还是静态的，而为了便于服务器和客户端处理，服务器响应之后，会立刻关闭连接。然而，这却为未来的互联网埋下了一场腥风血雨~

#### 跟一条金鱼讨论人生，HTTP和无状态协议
随着互联网和计算机的发展，我们的网页渐渐变得丰富，甚至是万能了起来（你甚至可以在网页上运行一个OS......）。而在网页会话的状态上，我们也渐渐有了需求——在登录淘宝购物时，要先登录才让购物，如果按HTTP无状态的特性来说，我们几乎每一个动作都需要登录一次，太不现实了。

#### 让金鱼拥有记忆，Session和Cookie
然鹅，魔高一丈，道高一尺！我们的卢姥爷—— *卢·蒙特利* 于1994年发明了Cookie，后续引出了我们今天的所要讨论的Session，为HTTP协议的**无状态连接**提供了**有状态**的补充。

通过实现一个**逻辑上的有状态**（是的，逻辑上的有状态，与WebSocket这样的技术不同，如果说WebSocket是两人在房间里面谈话，那么 Cookie 就是两人相互写信，不过彼此记得之前的谈话），我们就可以避免反复重复传输一部分数据，比如说登录认证信息。

>引用一下这两篇文章，对这部分内容讲解得很详细，由于本文重点不在这里，不过多篇幅讲解~~（虽然已经水了一大半）~~
>https://zhuanlan.zhihu.com/p/99986478
>https://www.cnblogs.com/cn-oldboy/p/12543519.html

# 抽象中的Session，Session与Cookie一个水果比香蕉好吃的故事
为什么Session要保留他模棱两可的诞生来头，其实是为了隐藏Session与Cookie不可告人的关系.....各位有所不知，这段经历早就美化过了......他真正的身份，就是......~~（后面忘了，总之就是卖钩子了）~~

言归正传，Cookie的出现是要早于Session的。先是发明了Cookie实现HTTP无状态的补充，而后在开发中，我们逐渐将**Cookie**从具体的实现**抽象**为前后端交互的一个**概念——Session**，而这也便是**Session**的身世，一个抽象的概念，名为 **“会话”**（或者说是一种**机制**）

## Tomcat中的HttpSession，狸猫换太子的故事
所以说，如果之前问出 **“Cookie和Session之间的区别？”** 这个问题，实际上是不合理的。毕竟一个抽象概念和他的实现要怎么比较呢？准确地来说，我们的问题应该被描述成 **“Cookie与Tomcat中Session的实现（HttpSession）的区别？”**

简单地来说 Cookie & HttpSession 这个问题，他的实现是基于类似这样的一个过程：
- 浏览器第一次访问服务器，服务器会响应回来一个SessionID，来维护本次的**会话**
- 浏览器接收到响应回来的SessionID，放入到Cookie中，成功地在双方之间建立一个“Session”。注意，此Session非彼Session，**是一个抽象意义上的逻辑的Session**（一次会话），而不是一个具体的Session（Tomcat中的HttpSession）
- 然后在后续的双方通信，每次浏览器带上Cookie访问服务器。服务器读取Cookie中的SessionID，服务器就能根据SessionID查询到对应的HttpSession，**继续两者之间逻辑上的会话**（实际应用上就是不用再进行登录验证）

总而言之，这里我们不重在讲解Cookie与Session之间的区别，而是重在提出Session这个抽象的概念“会话”，与他具体的实现（Tomcat的HttpSession）区分开。而在这里，也郑重地提出一句话：**Web一日尚存，Session永世不灭！**
 
# Session的变迁，从HttpSession到Redis + Session
计算机发展的洪流滚滚向前，历史的车轮无情地从Session&Cookie上碾过。当面对千家万户接入互联网的时候，数以万计的访问请求向我们的服务器袭来，面对这样的变遇，服务器的未来又该何去何从？

而历史告诉我们，服务器选择了分布式系统——通过组成**服务器集群**。但是，面对服务器集群，Session&Cookie的机制却~~犹如八十岁老太用手机一样~~束手无策——由于基于Tomcat的HttpSession与Cookie的机制，是基于一个进程中的，不能做到在多个进程，甚至是多台服务器上实现HttpSession的共享。

千呼万唤始出来，我们的Redis此时便派上用场了——**通过Redis实现分布式系统下的服务器集群Session共享**。

Tomcat中的HttpSession从本质上来看，也不过是我们Java进程中的一个数据结构，在内存上就是一组数据，所以从理论上来讲，我们可以把 HTTPSession 写入到 Redis 进行存储并统一管理。

由于本文章主要意在探讨原理，而且Redis+Session的实现在网上一搜一大把，在这里具体就不做讲解了。

讲完了Redis+Session，就到此为止了吗？不，我们还要谈谈他的另外一个兄弟——Token & JWT

# 登录验证从Session到Token，从有状态回到无状态

灵感戛然而止......