且听风定，再看句成。
Kimi K3 的技术博客里，有一个很容易被忽略、但很关键的细节： K3 对「思考历史」极度敏感。harness 如果没有完整传回之前的 thinking 内容，生成质量会严重不稳定。 原文大致写了两个触发条件： 1. harness 没有完整回传历史 thinking 内容 2. 会话中途从别的模型切换到 K3 博客对原因也做了解释。大多数 reasoning 模型，比如 Claude 的 ex
AIO BIO NIO区别？ BIO（同步阻塞 I/O） BIO 是传统的 I/O 模式，全称为 Block I/O，也叫同步阻塞 I/O。在 BIO 模式下，当我们执行 I/O 操作时，比如读取文件或者网络请求，程序会 阻塞，直到 I/O 操作完成后，才能继续执行后面的代码。也就是说，当一个线程在等待 I/O 完成时，它是处于阻塞状态的，不能做其他事情。 NIO（同步非阻塞 I/O） 一个线程管
cookie、session、token cookie 服务端发给客户端，交给客户端保存的数据，每次请求，客户端带上这些数据，服务端就读取这些数据，鉴别身份。 完全由客户端存储，和域名绑定，且不可跨域。 数据大小一般有限制。 容易被伪造，且客户端清除数据就丢失了 session 服务端将客户端的信息保存在服务端，然后将一个sessionId传给客户端，客户端保存起来，下次请求携带sessionId
MySQL锁 全局锁： flush tables with read lock，执行此条命令，整个数据库处于只读状态 unlock tables， 释放全局锁，会话断开时，也会自动释放全局锁 一般用来全库逻辑备份 表级锁：MySQL 里面表级别的锁有这几种： - - 表锁：通过lock tables 语句可以对表加表锁，表锁除了会限制别的线程的读写外，也会限制本线程接下来的读写操作。 - 元数据锁
垃圾收集器（CMS-G1-ZGC） CMS 垃圾收集器 JDK1.5时引入，JDK9被标记弃用，JDK14被移除 CMS（Concurrent Mark Sweep，并发标记清除）收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。 - 初始标记：Stop The World，仅使用一条初始标记
类加载机制/类加载器 类加载的完整流程（生命周期） 类从加载到卸载经历 5 个阶段，其中加载、验证、准备、初始化、卸载的顺序是固定的，解析阶段可能与初始化交叉进行： 1. 加载（Loading） - 任务：通过类的全限定名（如 ）获取其字节码数据，并生成 对象。 - 来源：字节码可来自本地文件、网络、数据库、动态生成（如 CGLib）等。 - 关键组件：类加载器（ClassLoader）负责此阶段
MVCC多版本并发控制 MVCC 的目标：让读操作尽量不阻塞写操作，写操作也尽量不阻塞读操作。 核心机制： MVCC主要依赖以下机制实现： 数据库行记录中的隐藏字段：最近修改本行数据的事务id、回滚指针指向本行数据的上个版本（其实是指向undo，通过undo计算上一个版本） •undo log：回滚日志，在insert、delete、update时产生，记载了与操作相反的操作，比如delete操作
SpringMVC执行流程 请求先到 DispatcherServlet（前端控制器），它负责调度 HandlerMapping → HandlerAdapter → Controller → ViewResolver → View。 Spring MVC 采用前端控制器模式，所有请求先进入 DispatcherServlet。DispatcherServlet 通过 HandlerMapping
MySqL事务隔离级别 事务的特性： 原子性：事务要么全部提交成功要么全部失败 一致性：事务操作前和操作后具有完整性约束，数据库保持一致性状态 隔离性：事务执行时相互隔离互不影响，可以防止多个事务并发执行由于交叉执行导致的不一致 持久性：事务操作结束后修改是永久性的，即使关机故障也不会消失 MySQL InnoDB 引擎通过什么技术来保证事务的这四个特性的呢？ - 持久性是通过 redo log
Redis的压缩列表ziplist到紧凑列表listpack ziplist 的结构（老版本用的） 大概长这样： 每个 里： - ：前一个 entry 的长度（1 或 5 字节） - ：当前 entry 是字符串还是整数，长度是多少 - ：真正的数据 listpack 的结构（新版本用的） 大概长这样： 每个 里： 注意两点变化： 1. 没有 prevlen 了（不再依赖“记录前一个元素长度”来反