IO多路复用模型：select、poll、epoll对比
IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼
用 Java + Spring 搭一个简单的 Agent
用 Java + Spring 搭一个简单的 Agent作为 Java 爱好者，很多人会问：Agent 开发是不是只能用 Python？其实不是 Agent 的核心是“调用模型 + 执行工具 + 循环”，用 Java 同样可以优雅地实现，并且能直接复用 Spring 生态里的依赖注入、配置、监控等能力 本文会一步步搭出一个可以扩展的 Agent 骨架：定义工具接口与注册表、封装模型客户端、实现带保护的 Agent 循环、暴露 REST 接口与会话存储，最后给出监控、测试、常见坑与迭代路线 让 Agent 调用 Java 业务能力的两种思路 很多企业的后端系统本身就是 Java 写的：订单、库存、权限、审批流都在 Spring 服务里
2026-10-14鱼鱼
JVM源码解析 从Launcher类浅谈ClassLoader(类加载器及双亲委派)
JVM源码解析 从Launcher类浅谈ClassLoader(类加载器及双亲委派)首先普及ClassLoader的基础：所有的Java类都是由ClassLoader由class文件加载进内存的，对于一个类，其唯一标识就是类名+加载他的ClassLoader（亦即对于不同的 ClassLoader，即使是加载了同一个Class也不能互通，本质上是两个类），其基本的分类如下图： BootstrapClassLoader是一个特殊的ClassLoader，负责启动时加载jre的类库 并不继承于ClassLoader，因为是jvm逻辑的一部分； ExtClassLoader也会加载jre类库，但是会加载那些额外的扩展类库(jre\lib\ext目录)，到这个级别的 类加载器已经可以直接在代码中使用了；
2020-11-28鱼鱼
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”前阵子我想补一块还不熟的中间件知识 打开文档、丢给 AI 一句“帮我讲讲原理和常见坑”，它讲得很顺，例子也漂亮 读完我心里有种熟悉的错觉：好像已经懂了 第二天动手搭一个最小示例，卡在配置项和错误信息上 再回头看昨晚的“懂”，其实只是跟着叙述走了一遍，脑子里没有自己踩过的脚印 这种“看完就觉得自己会了”，是我用 AI 学习时最常踩的坑 这篇文章不是反 AI，而是记我现在怎么用它学新技术，又怎么强制自己露馅、再补洞 写的都是个人习惯，不保证适合每个人，但对我自己很管用 AI 很擅长把陌生概念讲成一条平滑的故事线 平滑本身没问题，危险在于：故事线会掩盖你还不知道自己不知道的地方
2026-10-14鱼鱼
AI 自动补全抢方向盘：什么时候该关掉它
AI 自动补全抢方向盘：什么时候该关掉它AI 补全（或行内建议）最迷人的地方，是它常常「猜对你下一句」 最烦人的地方也是这个——它猜对下一句时，也可能把你带离本来要开的那条路 我不是补全黑名单派 体力活、重复模式、测试样板，我开着很香 但这篇文章想写清楚：哪些时刻我会主动关掉或忽略它，以及为什么「一直开着」会偷偷伤到设计质量 写给那些已经习惯 Tab，却说不清「这段到底是我想的还是它推的」的人 典型场景： 你正要抽一个接口，光标停在名字上，它已经按旧习惯补出一个「很大很全」的方法签名 你在探索两种方案，它持续把你推向仓库里更常见的那一种 你想写个丑但明确的临时实现，它不停建议「更优雅」的抽象 命名还没想清，它已经用空心词把名字钉死了
2026-10-15鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
ES快速入门(I)——分析分词器
ES快速入门(I)——分析分词器本文旨在快速入门Elasticsearch的分词，包括分词分析器的创建和介绍对比等，请确保在阅读前已经搭建好完备的集群 文章基于es7.0+，与稍旧版本的主要区别是没有type 在讨论分词前，我们先看一下es整体创建倒排的分词过程： 我们常说的分词器指的其实是“分析器”analyzer，es将以上常用的逻辑封装起来成为analyzer，但是语义上的分词器是指上面的tokenizer 经过了三层处理后拿到了terms数组建立最终的倒排索引： character filter：一般不会用到这个filter，是在分词前对原有的文档字段内容做转换，例如去除html的标签提取出正文内容，按正则清除和替换某些内容，你可以指定及自定义0个到多个character filter，他们将共同存在，一个文本流在经过character filter处理后，依然是文本流；
![ES快速入门(I)——分析分词器]()
2020-09-01鱼鱼
让 AI 写 SQL 和迁移脚本：语法没错，坑全在数据里
让 AI 写 SQL 和迁移脚本：语法没错，坑全在数据里在我日常用 AI 写的各种代码里，SQL 大概是“看起来最省心”的一类 语法它几乎不会写错，连窗口函数、递归 CTE 都信手拈来 让它写个报表查询，或者写个加字段的迁移脚本，几秒钟就好，读一遍也挑不出毛病 但正是这种“挑不出毛病”，让我吃过好几次亏 SQL 的坑很少出在语法上，而是出在语义、数据量和线上环境上——这三样东西，恰恰是 AI 在对话框里看不到的 这篇就把我踩过、或者差点踩到的坑整理一下，最后再说说我现在的做法 先交代背景：我平时主要接触 MySQL，也维护过一些 PostgreSQL 的项目 下面说到具体行为时，我尽量注明是哪个数据库；不同版本之间行为可能有差异，以你用的版本的官方文档为准
2026-10-14鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册如果你已经写过一两年 Go，会用 goroutine、channel，也能把一个 HTTP 服务跑起来，那么在准备中高级岗位面试时，大概率会发现：面试官问的已经不是“goroutine 怎么启动”，而是“一个阻塞的系统调用发生时，调度器会做什么”“nil 的 error 为什么不等于 nil”“线上 goroutine 数量一直涨，你怎么定位” 这类问题考察的不是背诵，而是你对运行时机制的理解，以及把机制翻译成工程判断的能力 这篇文章是一份按主题组织的复习手册 每个主题基本遵循同一个结构：典型面试题 → 参考回答思路 → 常见陷阱 → 简短的代码 内容覆盖调度器、goroutine 生命周期、channel、sync 原语、context、内存模型、GC 与逃逸分析、slice 与 map、interface、defer/panic/recover、泛型、错误处理、反射、并发模式、性能调优、工程实践，最后补充系统设计与行为面试的建议、速答表、学习路线和 FAQ
2026-10-14鱼鱼
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么和 Agent 多轮协作久了，会遇到一种安静的失败：它一直很忙，工具也在调，中间步骤看起来都“合理”，可收工时你发现——干的已经不是你起初要的那件事 我把这叫目标漂移（goal drift） 不是偶发幻觉那么简单，更像是上下文变长后，约束被一步步冲淡 这篇文章记我怎么发现漂移、怎么在过程中拉回，以及设计 Agent 时能做哪些防漂 常见几种面孔： 每一步单独看都有道理：重构有益、修复积极、干净也好 合起来却违背委托 危险在于局部合理、全局偏航 图：目标漂移四种脸：膨胀、替换、偷换、遗忘（原创示意图） 我的个人理解（含推测）： 所以漂移不完全是“模型不听话”，也是交互方式与系统设计的结果
2026-10-14鱼鱼
Agent 的评估、测试与可观测性：上线前后都要看得见
Agent 的评估、测试与可观测性：上线前后都要看得见Agent 的输出具有不确定性：同一个输入，两次运行的路径可能不同 传统的“写几个单元测试就放心”在这里行不通 本文介绍如何给 Agent 建立 评估（Evaluation） 与 可观测性（Observability） 体系：怎样拆解评估维度、构建评测集、选择打分方式、记录 Trace，并顺带讨论成本与延迟的护栏 文中给出 Python 的回归评测与 Trace 记录代码、Java 的埋点示例，以及常见坑和检查清单 评估分三层：结果层、过程层、效率层 传统软件的行为大多是确定的：相同输入得到相同输出，单元测试通过就有较强的信心 Agent 有三点不同： 非确定性：模型本身有随机性，同一任务可能走不同路径，甚至有时成功有时失败；
2026-10-14鱼鱼
