并发之AQS全解析
并发之AQS全解析我们知道juc(java.util.concurrent)包下有很多实用的类，提供了很多并发工具，例如线程池、原子类、并发工具、信号量工具、锁等，可以说基本实现都为悲观锁，底层原理基本都使用了AQS(AbstractQueuedSynchronizer)，AQS不是一种概念，是并发中实打实的工具类 本篇文章针对AQS做解析 AQS是多线程访问共享资源的同步器框架 AQS的资源可以是独占的也可以是共享的 我们先来简单看一下它的使用方式和ApI（因为是抽象类，是不能直接使用的）,下图是AQS的整体脉络 AQS核心就是一个状态值state，同时维护了一个线程的阻塞队列，队列的节点为有两种状态：SHARED(共享)和EXCLUSIVE(独占)，节点状态有五种：
![并发之AQS全解析]()
2021-03-12鱼鱼
Agent 跑批任务时我盯的几个「仪表盘」指标
Agent 跑批任务时我盯的几个「仪表盘」指标把 Agent 丢进一批任务里跑，最容易犯的错是：只盯最终答案 答案对了就庆祝，错了再翻日志 跑多了你会发现——很多失败在中途就已经写在仪表盘上了，只是你没看 这篇文章记我跑批（批量任务、夜间任务、评测集重跑）时会盯的几类指标 不是定行业标准，是我个人反复被坑后留下的观察清单 如果你也在用 Agent 刷题集、批量修测试、批量整理仓库，希望能少踩一点「早上起来只看见成功率」的坑 最终答案是结果，不是过程健康度 两类任务都可能「答对」： 走了一条干净路径，三步完成 绕了四十步，失败重试一堆，最后撞对 只看答案，你会把第二种也当成可上线策略 成本、稳定性、可复现性全被藏起来了
2026-10-15鱼鱼
工具调用（Function Calling）怎么设计才好用
工具调用（Function Calling）怎么设计才好用Agent 能不能“动手”，取决于工具调用 很多团队发现：模型明明够聪明，却总是选错工具、传错参数 问题往往不在模型，而在 工具设计 这篇文章从背景出发，讲清楚工具调用的完整流程，总结六条实用的设计原则，给出 Python 与 Java 两套防御式代码，并列出常见坑和检查清单 一次 Function Calling 的完整往返：模型只提请求，程序负责执行 大模型只能输出文字 让它“查天气”“下订单”“读数据库”，中间必须有一层翻译：模型用结构化的方式说出“我想做什么”，你的程序把它变成真实的函数调用 这一层翻译的质量，取决于你给模型的“说明书”写得怎么样 可以做个类比：工具定义之于模型，就像 API 文档之于新入职的后端同事
2026-10-14鱼鱼
DDD领域下的架构模式——CQRS架构
DDD领域下的架构模式——CQRS架构//TODO
![DDD领域下的架构模式——CQRS架构]()
2021-06-24鱼鱼
和 AI 结对写了一整天代码，我为什么比自己写还累
和 AI 结对写了一整天代码，我为什么比自己写还累有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写 我原本的预期是“今天应该会很轻松” 结果下班的时候，我累得比平时还厉害 不是手累，是脑子那种被掏空的累 回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度 那天晚上我想了挺久：问题到底出在哪？ 后来我又观察了自己几周，慢慢摸清楚了一些规律 这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法 我把那天的感受拆了一下，大概有五个来源 一是持续评审 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”
2026-10-14鱼鱼
AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
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鱼鱼
排坑指南-异步操作HttpServletRequest丢失Cookie
排坑指南-异步操作HttpServletRequest丢失Cookie遇到了一个很奇怪的bug：请求鉴权失败，因为通过Request对象获取到的Cookie中没有数据 经过debug调用request.getCookies()方法返回了null值，但是header属性的cookie却能拿到用户的有效cookie(request.getHeader("cookie"))，其中缘由，且慢慢道来 我们可以在web项目中通过Request对象很方便的获取Cookie对象： 但其内部实现其实有一层缓存逻辑，从名为"cookie"的请求头中读取并处理数据转为Cookie对象并不是个省时事，在org.apache.catalina.connector.Request类中可以看到如下代码实现：
2020-11-11鱼鱼
Agent 的评估、测试与可观测性：上线前后都要看得见
Agent 的评估、测试与可观测性：上线前后都要看得见Agent 的输出具有不确定性：同一个输入，两次运行的路径可能不同 传统的“写几个单元测试就放心”在这里行不通 本文介绍如何给 Agent 建立 评估（Evaluation） 与 可观测性（Observability） 体系：怎样拆解评估维度、构建评测集、选择打分方式、记录 Trace，并顺带讨论成本与延迟的护栏 文中给出 Python 的回归评测与 Trace 记录代码、Java 的埋点示例，以及常见坑和检查清单 评估分三层：结果层、过程层、效率层 传统软件的行为大多是确定的：相同输入得到相同输出，单元测试通过就有较强的信心 Agent 有三点不同： 非确定性：模型本身有随机性，同一任务可能走不同路径，甚至有时成功有时失败；
2026-10-14鱼鱼
Redis原理-源码解析：数据结构3 hash
Redis原理-源码解析：数据结构3 hash 所有原理实现基于Redis版本6.0.9 hash在Redis中可以认为是套了一层的string，当然，对hash来说没有数字类型 让我们依旧通过基本命令看看hash的基本数据结构实现 在set方法中我们看到了hash的初始创建过程，一个hash最开始是zipist 想要了解ziplist可以看Redis原理-源码解析：数据结构2 list ，是为节省内存而生的链表格式 所以其实在使用ziplist时其查询的时间复杂度不是遵循hash的近似O(1)，而是O(n)，但是在数据量不大时，这种性能的损失微乎其微，并且能预见到大多数使用hash的场景都不会存储过多的字段 所以优先使用了更节省内存空间的ziplist
2020-11-29鱼鱼
浅谈代理-动态代理
浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情，最基础的代理只需要定义一个接口(虽然不是必要，但这显然才是标准的设计)、一个被代理类和一个代理类，例如： 定义一个接口： 一个实现类： 和一个代理类： 实际使用时，我们是去调用HelloWorldProxy的方法，其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板，因为每一种代理行为都要制定一个代理类，我们熟知的很多基于代理的实现（譬如AOP、事务）显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类，这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发，JDK本身基于反射(java.lang.reflect)提供了动态代理，我们只需定义代理的行为，而对于代理类的范围并不是固定值
![浅谈代理-动态代理]()
2020-10-13鱼鱼
Agent 的重试与换路：失败了再试一次，还是换条路？
Agent 的重试与换路：失败了再试一次，还是换条路？做 Agent 的人，迟早会碰到同一个设计题：工具调用失败了，下一步是原地再试，还是换个策略？ 听起来像工程里的重试策略老话题，放到 Agent 里却更别扭——因为失败的原因经常不是“网络抖了一下”，而是“这条路根本走不通”，或者“模型把错误理解歪了，越重试越执着” 我踩过两边的坑：该重试时太早放弃，任务脆；该换路时死磕重试，账单和日志一起爆炸，最后还是失败 这篇整理一下我现在怎么做判断 不是所有失败都该一视同仁 我大致分成四类： 瞬时故障：超时、限流、连接重置 特征是：同一请求，过一会儿可能就好 输入问题：参数缺了、格式不对、路径不存在 特征是：原样再发，几乎必败 权限/策略拒绝：没权限、被安全策略拦住
2026-10-14鱼鱼
