并发之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 做得了，也不该让它独自按下 删除、推远程、改权限、对外部发消息——这类事一旦做错，回滚成本不对称 我把这类关卡叫做人类确认点（human gate）：Agent 可以准备好方案和命令，但执行前必须等人点头 原则很土：能撤销的可自跑，难撤销的先问人 我不太用“重不重要”来划分，而用“做错了能否廉价撤销” 易撤销： 改工作区文件、跑只读测试、本地格式化、生成草稿文档 中等： 本地 commit、加依赖但未推送、改本地配置 难撤销： force push、删数据、改生产配置、对客户发信、扩大公网权限、不可逆迁移 易撤销的，默认自动；难撤销的，默认闸门
2026-10-14鱼鱼
用 Java + Spring 搭一个简单的 Agent
用 Java + Spring 搭一个简单的 Agent作为 Java 爱好者，很多人会问：Agent 开发是不是只能用 Python？其实不是 Agent 的核心是“调用模型 + 执行工具 + 循环”，用 Java 同样可以优雅地实现，并且能直接复用 Spring 生态里的依赖注入、配置、监控等能力 本文会一步步搭出一个可以扩展的 Agent 骨架：定义工具接口与注册表、封装模型客户端、实现带保护的 Agent 循环、暴露 REST 接口与会话存储，最后给出监控、测试、常见坑与迭代路线 让 Agent 调用 Java 业务能力的两种思路 很多企业的后端系统本身就是 Java 写的：订单、库存、权限、审批流都在 Spring 服务里
2026-10-14鱼鱼
和 AI 结对写了一整天代码，我为什么比自己写还累
和 AI 结对写了一整天代码，我为什么比自己写还累有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写 我原本的预期是“今天应该会很轻松” 结果下班的时候，我累得比平时还厉害 不是手累，是脑子那种被掏空的累 回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度 那天晚上我想了挺久：问题到底出在哪？ 后来我又观察了自己几周，慢慢摸清楚了一些规律 这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法 我把那天的感受拆了一下，大概有五个来源 一是持续评审 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”
2026-10-14鱼鱼
kasper的算法（从0到1）
kasper的算法（从0到1）https://javaguide.cn/cs-basics/data-structure/linear-data-structure.html https://javaguide.cn/cs-basics/algorithms/linkedlist-algorithm-problems.html 项目地址：https://github.com/labuladong/fucking-algorithm 在线文档地址：https://labuladong.gitee.io/algo/home/ http://fishmaple.cn/blog/topicBlog?topicId=7
![kasper的算法（从0到1）]()
2023-10-23kasper
AI 自动补全抢方向盘：什么时候该关掉它
AI 自动补全抢方向盘：什么时候该关掉它AI 补全（或行内建议）最迷人的地方，是它常常「猜对你下一句」 最烦人的地方也是这个——它猜对下一句时，也可能把你带离本来要开的那条路 我不是补全黑名单派 体力活、重复模式、测试样板，我开着很香 但这篇文章想写清楚：哪些时刻我会主动关掉或忽略它，以及为什么「一直开着」会偷偷伤到设计质量 写给那些已经习惯 Tab，却说不清「这段到底是我想的还是它推的」的人 典型场景： 你正要抽一个接口，光标停在名字上，它已经按旧习惯补出一个「很大很全」的方法签名 你在探索两种方案，它持续把你推向仓库里更常见的那一种 你想写个丑但明确的临时实现，它不停建议「更优雅」的抽象 命名还没想清，它已经用空心词把名字钉死了
2026-10-15鱼鱼
浅析RPC框架Thrift
浅析RPC框架ThriftThrift是由Facebook开发的 RPC远程调用的框架，使用独有的Thrift协议进行可跨语言的远程调用 有点类似protobuf 无论使用何种语言，首先要准备Thrift编译环境，可以去官网下载相应的Thrift执行文件，下文均以Windows为例 下载后可以选择性的配置环境变量，最终在shell中可执行Thrift 在项目中，预先准备好libthrift依赖，maven写法： 例如： 定义一个testService.thrift（idl文件名不重要），一般都会定义在resources的thrift文件夹下： 这里定义了两个方法，分别返回字符串和int类型，在thrift的idl中，对于变量的定义如下：
2022-03-04鱼鱼
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”前阵子我想补一块还不熟的中间件知识 打开文档、丢给 AI 一句“帮我讲讲原理和常见坑”，它讲得很顺，例子也漂亮 读完我心里有种熟悉的错觉：好像已经懂了 第二天动手搭一个最小示例，卡在配置项和错误信息上 再回头看昨晚的“懂”，其实只是跟着叙述走了一遍，脑子里没有自己踩过的脚印 这种“看完就觉得自己会了”，是我用 AI 学习时最常踩的坑 这篇文章不是反 AI，而是记我现在怎么用它学新技术，又怎么强制自己露馅、再补洞 写的都是个人习惯，不保证适合每个人，但对我自己很管用 AI 很擅长把陌生概念讲成一条平滑的故事线 平滑本身没问题，危险在于：故事线会掩盖你还不知道自己不知道的地方
2026-10-14鱼鱼
Agent 记忆系统：短期记忆、长期记忆与向量库
Agent 记忆系统：短期记忆、长期记忆与向量库大模型本身是“无状态”的：每次请求都是一次全新的开始 Agent 之所以看起来“记得”你，是因为工程上做了 记忆系统 这篇文章梳理记忆的分类、常见实现方式、存储选型，并用可运行的代码演示短期记忆的摘要压缩与长期记忆的写入、召回，最后总结踩坑点和检查清单 记忆的三个层次：短期、长期与经验记忆 先看三个很常见的场景： 场景 A：用户上周说过“我的项目用 Java 17，不要给我 Java 8 的写法” 这周开新会话，Agent 又给出了 Java 8 的代码 用户会觉得“它根本不记得我” 场景 B：一个长任务跑了 40 步，到后半段 Agent 忘了最开始的约束“不要修改生产配置”
2026-10-14鱼鱼
MQTT 是什么：我把 pub/sub、QoS、遗嘱和 5.0 记一记
MQTT 是什么：我把 pub/sub、QoS、遗嘱和 5.0 记一记最近又有人问我「MQTT 到底干啥的」，我也发现自己讲的时候经常跳着说：一会儿 QoS，一会儿遗嘱，一会儿又冒出 5.0 的共享订阅 这篇就把常用概念按我自己理解串一遍 协议细节以 OASIS 规范为准，我没拿真机逐条抓包，标了「我推断」的地方别当标准条文 MQTT 全称历史上叫 Message Queuing Telemetry Transport 标准化过程里有人提过：名字里的 Message Queuing 容易让人联想到企业消息中间件，OASIS 后来更常直接叫它 MQTT，不再强调展开 事实是：它是一套 客户端—服务器 的 发布/订阅（publish/subscribe） 传输协议，设计目标就是报文小、实现简单，适合机器对机器（M2M）、物联网（IoT），以及带宽紧、延迟高、链路不稳的环境
2026-10-16鱼鱼
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析在Spring获取Context的源代码中，我们看到了对ClassUtil的方法调用，通过给定ClassName和ClassLoader进行Class的加载： ClassUtil.forName是仅供于Spring内部使用的获取Class对象的方法，来看一下源码： 首先 对于缓存的Class一块，在类的静态块中就能看出其逻辑： 在上面的resolvePrimitiveClassName方法中，先对长度做了一个判断，因为较长的packagename会影响执行的性能： 最终加载Class依旧是通过ClassLoader的，先来看一下获取ClassLoader的方法实现： 此处优先使用了ContextClassLoader作为 类加载器而非默认的AppClassLoader，在JVM源码解析 从 Launcher类浅谈ClassLoader中，提到了关于 类加载器的相关知识，使用ContextClassLoader是为了弥补双亲委派加载机制的对于自定义 类加载器的缺憾：那些自定义的 类加载器并没有机会上场，在使用了AppClassLoader后我们的自定义ClassLoader所加载的Class是无法被加载进去的，使用ContextClassLoader，我们可以在定义线程时，通过Thread的init方法(子线程调用，私有方法)或是setContextClassLoader直接指定使用自定义的ClassLoader
![JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析]()
2020-08-16鱼鱼
排坑指南-异步操作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鱼鱼
