Doraemon's Blog

理论基础 MDP（马尔可夫模型）：当前状态只和前面一个状态有关，目的是为了简化学习过程，认为当前状态就包含了过去的信息。与之相对的就是非马尔可夫过程，认为当前状态和前面的所有状态有关。 POMDP（部分马尔可夫可观测决策模型）：POMDP 是一种智能体无法直接观测到真实状态的决策模型。虽然系统的内部状态 仍然满足马尔可夫性（这点很关键），但智能体获得的只是状态的部分信息（观测值），因此对智能体来说，环境表现为非马尔可夫的。 模型 场景比喻 MDP 你在明亮的房间里走迷宫，看得清周围墙壁的位置，决策只需看当前。 POMDP 你在黑暗中走迷宫，只能凭手电照到的一小块区域和脚步声猜测位置。环境本身仍遵守马尔可夫性，但你“看不全”。 状态价值函数：当智能体在状态 s 下，按照策略 π 行动后，能获得的期望总回报。公式：$V^\pi(s) = \mathbb{E}_\pi [G_t | S_t = s]$。 动作价值函数：当智能体在状态 s 下采取动作 a，然后再按照策略 π 行动，能获得的期望总回报。$Q^\pi(s, a) = \mathbb{E}_\pi [ ...

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 的 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？拿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中的三种IO模型原理，以及优缺点