进程上下文到底是什么东西？
1. 进程上下文的总体分类一个进程的上下文主要分为三类：
用户级上下文（User-level Context）
内核级上下文（Kernel-level Context）
2. 各部分的内容（1）用户级上下文这是进程在用户态执行时的信息，主要包括：
用户虚拟地址空间（进程可访问的内存布局）：
代码段（Text Segment） → 存放程序的机器指令（只读）
数据段（Data Segment） → 存放全局变量、静态变量
BSS段（BSS Segment） → 存放未初始化的全局变量和静态变量
堆（Heap） → 动态分配（malloc/new）
共享库映射区 → 动态库、mmap
栈（Stack） → 函数调用、局部变量
用户栈内容（函数调用参数、返回地址、局部变量）。
用户态寄存器值（如 EAX、EBX、EIP、ESP 等）。
通用寄存器（AX、BX、CX、DX、RAX、RBX …）。
程序计数器 PC / 指令指针 IP（表示下一条将要执行的指令地址）
栈指针 SP（当前栈顶位 ...
协程食用指南
为什么需要协程？
高并发 I/O 场景：传统线程每创建一个都要占用较大内存（线程栈、内核数据结构等），当连接数达到数万、数十万时，线程开销和上下文切换代价太高。协程更轻量，可以同时管理大量并发任务（例如大量短暂的网络请求、文件 I/O）。
简化异步编程：用回同步风格（直线式代码）写异步逻辑，代码可读性好，容易维护。协程通过 suspend/await 等机制把异步逻辑写成像同步的流程。
更低的调度开销：协程通常在用户态由语言/运行时调度（或混合调度），上下文切换更快，资源消耗更小。
结构化并发：现代协程库支持“结构化并发”（父协程生命周期管理子协程），便于取消、超时和错误传播。
协程 vs 线程 —— 主要区别（要点）
调度层面：线程由操作系统调度（内核线程），协程通常由语言运行时/库在用户态调度（有的实现也支持把协程调度到多个内核线程上，比如 Go 的调度器或 Java 虚拟线程）。
创建/销毁成本：协程成本远小于线程（内存占用少、创建快）。
上下文切换：协程上下文切换开销小；线程上下文切换需要内核介入，代价大。
阻塞行为：线程阻塞只影响该线程；协程如果在单线程事件循环中执行阻塞操 ...
利用 Redis 实现分布式锁
利用 Redis 的 SETNX 命令，SETNX 全称是 “SET if Not Exists”，意为仅当指定的键不存在时，才设置该键的值，多线程调用 SETNX 可以保证有一个线程可以执行成功。
有加锁就有解锁，解锁需要判断持有锁的是否是当前线程（避免释放错锁），然后再释放，这是两步操作，需要保证原子性，放在 LUA 脚本里。
释放错锁的例子：假设线程 A 持有锁，在锁未释放前因阻塞（如睡眠、网络延迟）超过锁的过期时间，锁被自动释放。此时线程 B 获取到该锁，若线程 A 恢复后直接解锁，会错误地释放线程 B 持有的锁，导致其他线程可能趁机抢占锁，引发并发安全问题（如数据不一致）。
分布式锁的 key 和 value 的设置也是有讲究的，针对不同的资源或业务场景，需要使用不同的 key。例如：
操作用户 A 的订单时，key 可以是 lock:order:1001（1001 为订单 ID）。
操作库存时，key 可以是 lock:stock:product:2002（2002 为商品 ID）。
value 标识 “持有锁的线程 / 客户端”，用于解锁时校验身份，防止误解锁（ ...
分布式 ID 的生成方案
为什么需要分布式 ID？拿MySQL数据库举个栗子：
在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。
但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求，例如 user0 和 user1 两张表生成的 userid 如果采用自增 ID，会导致重复；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。
那么分布式ID需要满足那些条件？
全局唯一：必须保证ID是全局性唯一的，基本要求。
高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈。
高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性。
好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单。
趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求。
分布式 ID 的生成方案
UUID
数据库自增ID
数据库多主模式
号段模式
Redis ...
分布式事务
解决什么问题？我们都知道数据库可以通过事务来保证原子性操作，但实际场景中存在多个 DB实例或者微服务，例如扣减余额和扣减库存，如果余额和库存不在同一个 DB 实例中我们又该如何保证原子性操作？这就是分布式事务的概念。
首先需要铺垫一些理论：
CAP 理论CAP 定理是分布式系统中的一个重要定理，它指出在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个特性不能同时满足，最多只能满足其中两个。以下是对这三个特性的详细解释：
一致性（Consistency）：在分布式系统中，一致性指的是所有节点在同一时间具有相同的数据。也就是说，当一个数据在某个节点上被更新后，这个更新能够迅速传播到其他节点，使得所有节点都能看到最新的数据，就好像整个系统只有一个数据副本一样。例如，在一个分布式数据库中，如果一个用户在节点 A 上修改了一条记录，那么其他节点在查询该记录时，应该能够立即看到修改后的结果。
可用性（Availability）：可用性意味着系统中的每个请求都能得到响应，而不会出现长时间的等待或系统崩 ...
秋招-操作系统篇
Unix什么叫一切皆文件这个是 Unix 的一个核心哲学，我给你拆开讲：
“一切皆文件”是什么意思
在 Unix 系统里，几乎所有东西都用“文件”这种统一接口来访问：
普通文件：磁盘上的文本、二进制文件
目录：其实是存储文件名到 inode 的映射表
设备：键盘、显示器、硬盘、网卡都被抽象成“特殊文件”，放在 /dev 下
管道、FIFO、Socket：进程间通信对象，也以文件描述符的方式访问
甚至内核接口：比如 /proc、/sys 里的伪文件，用来读取系统信息
所以用户态只需要 open() / read() / write() / close() 这一套 API，就能操作各种资源，而不用关心底层差异。
为什么要这样设计
核心是抽象统一性：
简化接口：程序员不需要学习 N 套 API，读写磁盘和读写串口本质上没区别。
提高可移植性：应用只依赖标准文件 API，不管硬件怎么变，内核保证兼容。
增强组合性：因为统一成“文件”，就能用管道把命令组合起来（ls | grep txt | wc -l），这就是 Unix 强大的“工具拼装哲学”。
一个例子 🌰
打开一个磁盘 ...
Java的线程池
讲解了java中常见的线程池区别和使用方法
JAVA的三种IO模型
本文介绍了JAVA中的三种IO模型原理，以及优缺点
事务隔离级别及实现方式
前置知识按锁的粒度分类
记录锁（Record Lock）：属于单个行记录上的锁。
间隙锁（Gap Lock）：锁定一个范围，不包括记录本身，间隙锁之间不冲突，不分排他和共享。
临键锁（Next-Key Lock）：Record Lock+Gap Lock，锁定一个范围，包含记录本身，主要目的是为了解决幻读问题（MySQL 事务部分提到过）。记录锁只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁，左开右闭。
在 InnoDB 默认的隔离级别 REPEATABLE-READ 下，行锁默认使用的是 Next-Key Lock。但是，如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock，即仅锁住索引本身，而不是范围。
表级锁：锁定整张表。
这里只提一点，行级锁锁住的是索引字段，而表级锁才是在物理存储上锁住了表，没有命中唯一索引或者索引失效的话，就会导致扫描全表对表中的所有行记录进行加锁。不过，很多时候即使用了索引也有可能会走全表扫描，这是因为 MySQL 优化器的原因，一些情况下全表扫描更快，比如索引碎 ...
