面试 on Coder_Studio

一篇搞懂：LangChain4j结构化输出、TokenStream、SSE、Flux、Reactor到底是什么？

Thu, 26 Mar 2026 20:42:49 +0000

结构化输出、TokenStream、SSE、Flux、Reactor这几个概念刚接触时感觉很混乱，本文就来理一理，我用【AI生成一个电商商品详情页】的真实项目场景，把这些概念串起来，从业务需求到底层技术，一次性搞明白。

LangChain4j结构化输出

结构化输出是LangChain4j里的一个核心功能，能强制大模型返回标准的JSON/POJO组件树对象，而不是一段诸如“我给你加个按钮、加个图片”的自然语言。

之前你让AI生成商品详情页，它可能返回：

“好的，我帮你生成了一个详情页，顶部有个轮播图放3张商品图，中间有商品标题、价格、库存，底部有个‘立即购买’的红色按钮…”

然后你还得写自己大量文本解析逻辑，甚至还要用正则去提取轮播图数量、按钮颜色，又繁琐又容易出错，而且根本没法直接渲染成 Web 组件。

用了结构化输出，AI 会直接返回标准 JSON，之后 LangChain4j 会自动把 JSON 转成 Java 对象。底层默认使用 Jackson（Java 最主流的 JSON 库），只需要提前定义好页面结构的模板类，系统就能自动完成字段映射，完全不用写任何解析代码，直接就能喂给前端的渲染引擎。

TokenStream + SSE

TokenStream是LangChain4j提供的流式API，大模型生成一个Token（大概是一个字、半个JSON键或值），就立刻推给你，不用等整个组件树JSON生成完；

SSE（Server-Sent Events），把TokenStream里的JSON片段，实时推给前端的渲染引擎，实现“轮播图先出来、标题再出来、按钮最后出来”的逐个渲染效果。

之前你让AI生成一个复杂的Web应用，要等10-30秒整个JSON生成完，才能一次性渲染给用户，用户需要在空白的预览区页面长时间等待。

用了TokenStream + SSE，AI生成完一个完整的组件JSON片段，前端就立刻渲染这个组件，用户能实时看到进度。

Flux & Reactor

Reactor是Spring官方的响应式编程框架，专门用来处理高并发、异步、流式的场景；

Flux是Reactor的核心类之一，代表0到N个元素的异步序列，刚好对应AI生成的JSON片段流（一个JSON片段就是一个元素）。

如果用传统的同步编程，几百个用户同时请求生成Web应用，你需要开几百个线程，每个线程都要等10-30秒AI生成完，服务器的CPU、内存直接就爆了，根本扛不住。

用了 Flux + Reactor，就能彻底解决这个问题：

它是完全异步非阻塞 + 事件驱动的模型 —— 发起 AI 调用后，线程立刻释放去处理其他请求，绝不死等；等 AI 生成 Token 后，再主动通知线程来处理推送，1 个线程能同时管理几百个请求，所以只用 10-20 个线程就能扛住几百甚至上千的并发。

另外，它还自带背压机制：前端网速慢，服务端就自动放慢推送速度；前端快，就加快推送，永远不会让前端浏览器因为数据堆积而卡死。

一张图搞懂

【面试真题拆解】十万用户并发下，Caffeine+Redis+MySQL多级缓存怎么设计？

Thu, 26 Mar 2026 14:59:06 +0000

面试官问了这么一道场景题：

“平台用了Caffeine本地缓存、Redis分布式缓存、MySQL数据库，现在有十万个用户同时访问，相当于每个用户对应一个请求，这多级缓存该怎么设计？”

多级缓存就是“分层扛压”，把十万用户的请求，从快到慢、从近到远，一层层分流，别让所有请求都直接打MySQL。

设计方案

定好每一层的职责

缓存层级	职责	放什么数据	容量/速度
Caffeine本地缓存	扛超级热点中的超级热点，大幅减少 Redis 压力	访问频率 Top10 的极致热门数据（比如首页轮播爆款、正在进行的秒杀活动）	容量小（几百MB）、速度极快（纳秒级）
Redis分布式缓存	扛全局通用数据，挡MySQL	全平台的业务数据（比如商品详情、用户信息、订单数据）	容量大（几十GB）、速度快（毫秒级）
MySQL数据库	数据最终兜底，保证数据不丢	所有的原始业务数据	容量无限、速度慢（秒级）

缓存预热

平台刚启动的时候，Caffeine和Redis里都是空的，如果这时候十万用户同时进来，所有请求都会直接打MySQL，直接把数据库打垮。

为了解决这个问题，考虑采用缓存预热：

平台启动前，先做两级缓存预热：

把访问频率最高的Top1000 个全量热门 Key（比如全平台热门商品、活动规则），提前从 MySQL 里查出来，全量加载到 Redis；
把其中访问频率最高的Top10 个超级热点 Key（比如首页轮播商品、正在进行的爆款活动），额外加载到每台服务器的 Caffeine 本地缓存，作为最外层的扛压层。

缓存雪崩、击穿、穿透

缓存雪崩：十万个Key同时过期

比如你给所有Key都设置了“1小时过期”，结果十万个Key在同一时间全部过期，所有请求直接打MySQL。

解决这个问题的话，就是别给所有Key都设一样的过期时间，可以设置“1小时 + 0~30分钟的随机值”，让Key的过期时间分散开，避免同时过期；

对于首页Top10商品这种超级热点数据，还可以设置成“永不过期”，只在数据更新的时候主动删除缓存。

缓存击穿：超级热门Key突然过期

比如“双11爆款商品详情”这个Key，每秒有十万个请求，结果它突然过期了，十万个请求同时打Redis，发现没有，又同时打MySQL，直接把两者都打垮。

这个问题也可以对超级热点Key不设过期时间，只在更新时主动删；

或者加Redis 分布式互斥锁：

如果 Key 真的过期了，只让第一个抢到锁的请求去查 MySQL，查出来后更新缓存并释放锁；

其他没抢到锁的请求，每隔 100ms 重试一次查缓存，直到缓存更新完成，彻底避免十万请求同时打 MySQL。

缓存穿透：查根本不存在的Key

比如有人恶意攻击，每秒发十万个请求查“id=999999999”的商品（这个商品根本不存在），缓存里没有，直接打MySQL，把数据库打垮。

这个问题优先采用布隆过滤器拦截：

平台启动时，提前把 MySQL 里所有商品的 id 全量加载到布隆过滤器里完成预热；
用户请求进来，先过布隆过滤器，如果布隆过滤器判定这个商品 id 不存在，直接返回【商品不存在】，完全不会打到缓存和 MySQL；
只有布隆过滤器判定 id 存在，才会继续走【Caffeine→Redis→MySQL】的查询流程。

兜底方案：

缓存空值。如果查 MySQL 发现这个 Key 真的不存在，就把【空值】缓存到 Redis 里（设置 5 分钟短过期时间），下次再查这个 Key，直接从 Redis 里拿空值返回，避免重复打 MySQL。

小贴士：

空值缓存必须设置短过期时间（3-5 分钟），同时限制单 IP 的请求频率，避免恶意攻击生成大量空值缓存撑爆 Redis 内存。

十万并发下的 Redis 压力分摊方案

十万个请求同时进来，如果都打到单实例 Redis 上，大概率会直接把 Redis 打宕机，必须做以下 3 件事分摊压力：

热点隔离，本地优先扛压：把访问频率 Top10 的极致超级热点 Key（比如首页轮播爆款、正在进行的秒杀活动），全量放在每台服务器的 Caffeine 本地缓存里。十万请求里 90% 都能直接在本地命中，Redis 的压力直接降 90%。
用 Redis Cluster 集群，把数据分片存储在多个节点上，每个节点只扛一部分请求，避免单节点压力过载；
Redis 主节点只负责数据更新的写请求，多个从节点负责处理十万级的读请求，把读压力分摊到多个从节点上。

多实例下的本地缓存一致性

服务基本都是多实例集群部署的（比如 10 台服务器），每台服务器都有自己独立的 Caffeine 本地缓存，很容易出现数据不一致的问题：

比如在 A 实例更新了商品价格，删了 A 实例的 Caffeine 和 Redis 缓存，但 B 实例的 Caffeine 里还存着旧价格，用户访问 B 实例就会看到脏数据。

考虑用延迟双删 + Redis 发布订阅的组合方案解决这个问题：

延迟双删：保证 Redis 和 MySQL 的数据一致

① 先删除 Redis 缓存，让缓存失效；

② 再更新 MySQL 数据库，写入新数据；

③ 等待 1 秒（延迟时间必须略大于你的业务接口平均耗时，根据实际压测结果调整，不能盲目设置），再次删除 Redis 缓存。

延迟的目的是等其他实例已经从 MySQL 读到旧数据、更新到缓存后，再删一次缓存，避免脏数据回写。

Redis 发布订阅：保证多实例 Caffeine 的数据一致

①A实例更新完数据、完成延迟双删后，通过 Redis 的发布订阅功能，给集群里所有服务实例广播一条消息：商品 id=123 的缓存已失效，请删除本地缓存；

②所有实例收到消息后，立刻删除自己本地Caffeine里对应的Key；

③下次用户访问任何实例，都会去 Redis 里查询新数据，再更新到本地 Caffeine，保证全集群所有实例的数据一致。

完整的请求+数据更新全流程

【面试真题拆解】你知道登录用到的Token是什么吗？

Thu, 26 Mar 2026 12:06:32 +0000

用户注册登录模块几乎是每一个项目都有的，有一次面试的时候，面试官问：

你既然说到了登录，那你知道Token是什么吗？

一句话：

Token = 用户登录成功后，服务器给你颁发的一张加密的临时电子通行证，最常用的就是 JWT 格式的 Token。

它本质上就是一段加密字符串，作用就是证明三件事：你是谁、你已登录、你有权限访问这个接口。

为什么登录必须用 Token？

因为 HTTP 请求是无状态的——服务器记不住你上一秒是不是登录过。
每一次请求，对服务器来说都是“陌生人”。

所以必须给你发一张 Token，让你每次访问都带着，证明你已登录。

不然你每次点一下页面都要重新输账号密码，根本没法用。

Token 的工作流程

Token 的作用

Token 和 Session 的区别

存的地方不一样
Session 把你的身份信息全存在服务器，用户一多就特别占内存；
Token 是把“电子通行证”直接存在你自己的前端设备里，服务器不用存任何用户状态，只需要验一下通行证的真假就行，几乎没额外负担。
分布式场景的适配能力不一样
Session 不适合多服务器的分布式场景——就像你在1号窗口办的会员，2号窗口根本不认，得来回同步数据，麻烦得很；
Token 就没这个烦恼，你手里的通行证全平台通用，不管哪个服务器，只要能验过真伪就直接放行，天生就适配分布式。

说白了，Token 就是为了解决 HTTP 无状态的痛点，给前端和后端之间搭了一座信任的桥梁，不用每次都输账号密码，不用服务器存储大量用户状态，还能完美适配现在的分布式项目。

【面试真题拆解】为什么用SSE做流式输出？和WebSocket有啥区别？

Wed, 25 Mar 2026 17:41:32 +0000

面试官问：

“你项目里用了SSE做流式输出，为什么选SSE？它的原理你知道吗？为什么不用WebSocket？”

为什么用SSE做流式输出？

一句话：

SSE 是为服务器单向给客户端推数据的场景量身定做的，完美匹配 AIGC 流式打字机的需求，开发简单、好用、运维成本低。

类比：

SSE 就像广播电台：电台单向给你播新闻、播音乐，你只能听，不能对着电台说话；
WebSocket 就像打电话：你和对方可以双向说话，你一句我一句，实时互动。

SSE流式输出的原理

SSE是Server-Sent Events（服务器发送事件），本质上是一条由服务器控制生命周期的持久化 HTTP 长连接，在数据推送周期内保持打开，不会像普通 HTTP 请求一样响应完成就立刻关闭。

完整的流程就是：

客户端发起请求

浏览器向服务器发起一个普通的HTTP GET请求，但请求头里要加 Accept: text/event-stream，告诉服务器：“我要接收流式数据，别给我返回普通网页”；

服务器建立长连接

服务器收到请求后，不立刻返回完整响应，而是保持这条HTTP连接一直打开，不关闭；

服务器持续推数据

服务器有新数据了（比如AI生成了一个字），就通过这条打开的连接，把数据推给客户端；

SSE 有固定的标准文本格式，每段数据以data:开头、\n\n结尾，刚好适配大模型逐 Token 生成的流式输出，后端生成一个 Token 就推一次，前端无需额外做格式解析，直接渲染成打字机效果；

客户端解析数据

浏览器收到数据后，自动解析，触发 onmessage 事件，前端把数据展示出来；

连接结束或自动重连

如果数据推完了，服务器就会主动关闭连接；

如果连接意外断开（非手动关闭、非服务器返回 204 状态码），SSE 自带自动重连机制，浏览器会自动重新发起请求，还会通过请求头Last-Event-ID带上最后接收的消息 ID，后端可据此补发丢失的内容，避免 AI 回答断句缺失，建立新连接后继续接收数据。

为什么不用WebSocket？

WebSocket 是为双向实时交互场景设计的，对于 AI 流式输出这个纯服务器单向推数据的场景，有点那什么杀鸡用牛刀了，并且额外增加了开发、运维成本，完全没有必要。

对比项	SSE（Server-Sent Events）	WebSocket
通信模式	单工，纯单向通信：仅支持服务器向客户端主动推送数据，客户端只能被动接收	全双工，双向通信：客户端和服务器可以同时、双向主动发送数据，无请求 - 响应的限制
协议本质	标准 HTTP 应用层协议，完全兼容所有 HTTP 基础设施（Nginx、CDN、网关、防火墙），无需额外配置	独立的应用层协议，底层基于 TCP，仅握手阶段复用 HTTP，握手完成后需协议升级，部分内网网关、WAF 会拦截升级请求
开发复杂度	极低：浏览器原生提供`EventSource` API，前端几行代码即可实现；后端仅需开发普通 HTTP 接口保持连接推送数据，无需额外处理协议逻辑	较高：需要自行处理连接握手、心跳保活、断线重连、TCP 粘包拆包、帧解析等逻辑，前后端都需要额外的开发工作量
自动重连	原生支持：浏览器内置自动断线重连机制，无需额外开发	无原生支持：需要自行实现心跳检测和断线重连逻辑
适用场景	服务器单向推送场景：AIGC 流式打字机效果、股票行情推送、直播弹幕、新闻实时更新	双向实时交互场景：即时通讯、实时多人游戏、视频会议、物联网设备双向控制

【面试真题拆解】平时会收发短信吧？你知道短信里那种 `CodeEdge` 的短链接，点击之后是怎么跳转到长链接的？它是怎么生成的？

Tue, 24 Mar 2026 21:34:02 +0000

面试官问：

“平时会收发短信吧？你知道短信里那种 xxxxx 的短链接，点击之后是怎么跳转到长链接的？它是怎么生成的？”

点击短链接后发生了什么？

两个字：重定向。

用户点击短链接

比如用户点击 t.cn/xu0324；

浏览器请求短链接服务器

浏览器向 t.cn 的服务器发送HTTP请求，要访问 /xu0324 这个路径；

服务器查映射关系

服务器去数据库或者Redis里查，发现 xu0324 对应的原始长链接是 https://www.CodeEdge.com/xxx；

服务器返回重定向响应

服务器不返回网页内容，而是返回一个 HTTP 302状态码，并在响应头 Location 里填上原始长链接；

浏览器自动跳转

浏览器收到302状态码，看到 Location 里的长链接，自动发起新的请求，访问原始长链接；

之后，用户就看到了原始长链接的页面。

那个短链接是怎么生成的？

目前主流的生成算法有3种：

自增ID + Base62编码

用分布式ID生成器（比如雪花算法），生成一个全局唯一的自增数字ID（比如 1, 2, 3, …），再把这个10进制的数字ID，转换成62进制的字符串（Base62）。

这种方案因为是自增ID，每个ID对应唯一的Base62字符串，所以绝对唯一，没有哈希冲突，而且不涉及复杂的哈希计算，生成速度极快。

小贴士

什么是Base62呢？平时用的是10进制（0-9），Base62其实是0-9（10个）、a-z（26个）、A-Z（26个），加起来总共62个字符，所以叫Base62。

哈希算法+截取

对原始长链接做MD5或SHA-1哈希，得到一个32位（或更长）的哈希字符串，再截取哈希字符串的前6位或8位，作为短链接后缀。

这种方案对于两个不同的长链接，哈希后的前6位可能会一样，从而导致映射错误；如果发现了冲突，需要换一种截取方式（比如截取中间6位），或者加盐重新哈希，但这样也增加了复杂度。

随机字符串生成

直接随机生成一个6位的Base62字符串，再去数据库里查，如果这个字符串已经被占用了，就重新生成，直到生成一个没有被占用的。

这种方案会随着链接越来越多，冲突概率越来越大，可能要重试很多次才能生成一个可用的；并且高并发下，多个请求可能会同时生成同一个随机字符串，导致数据库唯一键冲突，所以不适合高并发场景。

为什么要用短链接？

1. 短信的字数限制

因为一条短信最多只能发70个汉字（或160个英文字符），如果直接发一个几百个字符的长链接，一条短信根本发不下，要拆成好几条，成本也会相应增加；如果用短链接，只需要十几个字符，就能完美解决字数限制的问题。

2. 防拦截、防屏蔽

长链接里经常包含很多参数，很容易被运营商、手机安全软件识别为“营销链接”或“钓鱼链接”，直接拦截，但如果用短链接的话，看起来很干净，被拦截的概率就会大大降低。

3. 数据统计和追踪

短链接服务器可以记录谁在什么时候、通过什么设备、点击了这个链接，企业通过这些数据，可以分析营销效果、用户画像、转化率等等。

【面试真题拆解】Java里面的线程池都有哪些参数？

Sun, 22 Mar 2026 15:09:10 +0000

那下一个问题，面试官接着问：

“ Java里面的线程池都有哪些参数？”

我当时就记得“核心线程数、最大线程数”，其他的应该还有5个，支支吾吾答不上来，直接就凉了。

线程池是用来管理线程的，避免频繁创建和销毁线程带来的性能开销。

类比一下工厂招工：

不用线程池

来一个任务就招一个新工人（创建线程），任务干完就辞退（销毁线程），频繁招工辞退，效率极低，还费钱；

用线程池

工厂提前招好一批固定工人（核心线程），任务来了直接让固定工人干，固定工人忙不过来就把任务放待办队列（工作队列），队列也满了就临时招几个临时工（非核心线程），临时工没活干了过段时间就辞退，效率高，还省钱。

线程池的7个核心参数

Java线程池的核心类是 ThreadPoolExecutor，它的构造方法有7个参数：

1. corePoolSize：核心线程数

工厂的正式工数量。

正式工是工厂的“长期工”，默认情况下，就算没活干，也不会被辞退；

任务来了，先让正式工干，正式工没满的话，直接创建正式工执行任务。

2. maximumPoolSize：最大线程数

工厂的正式工+临时工的总数量。

正式工忙不过来，待办队列也满了，就会招临时工；

正式工+临时工的总数，不能超过最大线程数。

3. keepAliveTime：空闲线程存活时间

工厂的临时工没活干的时候，多久会被辞退。

只有临时工（非核心线程）会被回收，正式工（核心线程）默认不会被回收；

但是，如果设置了 allowCoreThreadTimeOut(true)，正式工没活干了，过了这个时间也会被辞退。

4. unit：时间单位

空闲线程存活时间的单位。

比如 TimeUnit.SECONDS（秒）、TimeUnit.MINUTES（分钟）、TimeUnit.HOURS（小时）。

5. workQueue：工作队列

工厂的待办任务队列。

正式工（corePoolSize）都在忙，新任务来了就先放进待办队列，等正式工有空了再从队列里拿任务干。

6. threadFactory：线程工厂

给工厂的工人起名字的。

用来创建新线程，给线程设置名字、优先级、是否是守护线程等。

7. handler：拒绝策略

工厂的任务太多了，正式工、临时工、待办队列都满了，怎么处理新任务，就是靠这个参数定义的。

线程池的执行流程

提交新任务

工厂来了一个新任务；

判断核心线程数

先看正式工（corePoolSize）有没有满，没满的话，直接招一个正式工（创建核心线程）执行任务；

判断工作队列

如果正式工满了，就看待办队列（workQueue）有没有满，没满的话，把任务放进队列，等正式工有空了再拿；

判断最大线程数

如果队列也满了，就看正式工+临时工的总数（maximumPoolSize）有没有满，没满的话，招一个临时工（创建非核心线程）执行任务；

执行拒绝策略

如果最大线程数也满了，就执行拒绝策略（handler），处理这个新任务；

任务执行完

线程执行完任务，会从队列里拿下一个任务继续干；

空闲线程回收

如果是临时工（非核心线程），没活干的时间超过了 keepAliveTime，就会被回收（辞退）。

4种默认拒绝策略

拒绝策略	作用	适用场景
AbortPolicy（默认）	直接抛出RejectedExecutionException异常，拒绝执行新任务	对数据一致性要求高的场景，任务不能丢，必须让调用者知道任务被拒绝了
CallerRunsPolicy	由提交任务的线程（调用者线程）自己执行这个任务	对性能要求不高，任务不能丢的场景，比如日志记录
DiscardPolicy	直接丢弃新任务，不抛异常，也不做任何处理	对数据一致性要求不高，丢几个任务没关系的场景，比如非核心的监控数据上报
DiscardOldestPolicy	丢弃队列里最老的任务（等待时间最长的任务），然后把新任务放进队列	对数据一致性要求不高，但想尽量执行新任务的场景

ThreadPoolExecutor 的构造方法

import java.util.concurrent.*;

/**
 * 线程池示例
 */
public class ThreadPoolDemo {
    public static void main(String[] args) {
        // 定义线程池的7个核心参数
        ThreadPoolExecutor threadPool = new ThreadPoolExecutor(
                5, // corePoolSize：核心线程数（5个正式工）
                10, // maximumPoolSize：最大线程数（5个正式工+5个临时工）
                60, // keepAliveTime：空闲线程存活时间（60秒）
                TimeUnit.SECONDS, // unit：时间单位（秒）
                new ArrayBlockingQueue<>(100), // workQueue：有界队列（容量100）
                Executors.defaultThreadFactory(), // threadFactory：默认线程工厂
                new ThreadPoolExecutor.AbortPolicy() // handler：默认拒绝策略（抛异常）
        );

        // 提交任务
        for (int i = 0; i < 200; i++) {
            final int taskId = i;
            threadPool.execute(() -> {
                System.out.println(Thread.currentThread().getName() + " 执行任务：" + taskId);
            });
        }

        // 关闭线程池
        threadPool.shutdown();
    }
}

【面试真题拆解】Java的Static关键字到底怎么用？

Sun, 22 Mar 2026 13:06:05 +0000

面试官上来就问：

“ 那个Java里面的Static关键字，一般是怎么用？”

一句话：

Static是“类级别的”，不是“实例级别的”。

被Static修饰的东西，属于整个类，所有实例共用一份，不用new对象就能直接用；

而没被Static修饰的东西，属于单个实例，每个实例有自己的一份，必须new对象才能用。

对比项	静态（Static）	实例（非Static）
归属	属于整个类	属于单个实例
内存位置	方法区（JDK8 之后叫元空间）	堆内存
访问方式	类名.（变量/方法），或（实例.变量/方法）（不推荐）	必须通过实例.变量/方法访问
共享性	所有实例共用一份	每个实例有自己的一份
初始化时机	类加载时初始化	创建实例时初始化
访问限制	只能直接访问静态成员	可以访问静态成员和实例成员

1. 静态变量

静态变量就像是整个类共享的“公共储物柜”，所有实例共用这一个柜子，你放进去的东西，别人也能拿到；而实例变量是每个实例自己的“私人储物柜”，互不干扰。

举个例子，用静态变量做全局计数器

/**
 * 网站访问计数器
 */
public class WebsiteCounter {
    // 静态变量：所有实例共用，统计总访问次数
    public static int totalVisitCount = 0;
    // 实例变量：每个实例自己的，统计单个用户的访问次数
    public int userVisitCount = 0;

    /**
     * 访问方法
     */
    public void visit() {
        // 修改静态变量：总访问次数+1
        totalVisitCount++;
        // 修改实例变量：单个用户访问次数+1
        userVisitCount++;
    }

    public static void main(String[] args) {
        // 用户1访问
        WebsiteCounter user1 = new WebsiteCounter();
        user1.visit();
        user1.visit();
        System.out.println("用户1访问次数：" + user1.userVisitCount); // 输出2
        System.out.println("总访问次数：" + WebsiteCounter.totalVisitCount); // 输出2

        // 用户2访问
        WebsiteCounter user2 = new WebsiteCounter();
        user2.visit();
        System.out.println("用户2访问次数：" + user2.userVisitCount); // 输出1
        System.out.println("总访问次数：" + WebsiteCounter.totalVisitCount); // 输出3
    }
}

2. 静态方法

静态方法是属于类的“公共工具”，不用new对象，直接通过【类名.方法名】就能调用，而实例方法是属于单个实例的，必须new对象之后才能调用。

举个例子，用静态方法做工具类

/**
 * 字符串工具类
 */
public class StringUtils {
    // 私有构造方法：从根源上禁止外部代码 new StringUtils()
    // 工具类全是静态方法，完全不需要实例化，这样做能强制大家用[类名.方法名]的正确用法
    private StringUtils() {}

    /**
     * 静态方法：判断字符串是否为空
     */
    public static boolean isEmpty(String str) {
        return str == null || str.trim().isEmpty();
    }

    /**
     * 静态方法：字符串反转
     */
    public static String reverse(String str) {
        if (isEmpty(str)) {
            return str;
        }
        return new StringBuilder(str).reverse().toString();
    }

    public static void main(String[] args) {
        // 直接通过类名调用静态方法，不用new对象
        System.out.println(StringUtils.isEmpty("")); // 输出true
        System.out.println(StringUtils.reverse("hello")); // 输出olleh
    }
}

3. 静态代码块

静态代码块是类加载的时候执行一次，且只执行一次的代码块，用来初始化静态变量或者做一些类级别的准备工作（比如加载配置文件、初始化数据库连接池）。

举个例子，用静态代码块初始化静态配置

/**
 * 配置类
 */
public class Config {
    // 静态变量：数据库连接地址
    public static String dbUrl;
    public static String dbUsername;
    public static String dbPassword;

    // 静态代码块：类加载时执行一次，初始化静态变量
    static {
        System.out.println("静态代码块执行，开始初始化配置...");
        // 模拟从配置文件读取配置
        dbUrl = "jdbc:mysql://localhost:3306/test";
        dbUsername = "root";
        dbPassword = "123456";
    }

    // 实例代码块：创建实例时执行，每次new都执行
    {
        System.out.println("实例代码块执行...");
    }

    // 构造方法：创建实例时执行，每次new都执行
    public Config() {
        System.out.println("构造方法执行...");
    }

    public static void main(String[] args) {
        // 第一次访问Config类，触发类加载，静态代码块执行
        System.out.println("数据库地址：" + Config.dbUrl);
        System.out.println("---");
        // new第一个实例，实例代码块和构造方法执行
        new Config();
        System.out.println("---");
        // new第二个实例，实例代码块和构造方法执行，但静态代码块不再执行
        new Config();
    }
}

小贴士

静态代码块只在类第一次被加载时执行一次，之后不管new多少个实例，都不会再执行。

4. 静态内部类

静态内部类是属于外部类的“独立房间”，不用依赖外部类的实例就能直接创建，而非静态内部类是属于外部类实例的“附属房间”，必须先有外部类实例才能创建。

静态内部类的作用是：

利用 Java 的类加载时机，实现了懒加载（用的时候才创建）+ 线程安全（JVM 保证）+ 不用加锁（性能高）的完美单例。

举个例子，用静态内部类实现线程安全的单例模式

/**
 * 单例模式：静态内部类实现
 */
public class Singleton {
    // 私有构造方法：从根源上禁止外部代码直接 new Singleton()
    private Singleton() {}

    // 静态内部类：只有第一次被访问时才会加载（实现懒加载，用的时候才创建实例，不占内存）
    // 因为是在 Singleton 类内部，所以可以访问上面的 private 构造方法
    private static class SingletonHolder {
        // 静态变量：JVM 类加载过程是天然线程安全的，这里初始化唯一的单例实例（不用加锁，性能高）
        private static final Singleton INSTANCE = new Singleton();
    }

    // 全局唯一的访问点：外部代码只能通过这里获取单例实例
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    public static void main(String[] args) {
        // 获取单例实例
        Singleton instance1 = Singleton.getInstance();
        Singleton instance2 = Singleton.getInstance();
        // 两个实例是同一个，完美实现单例
        System.out.println(instance1 == instance2); // 输出true
    }
}

小贴士

静态变量存放在JVM的方法区（元空间），不是堆内存。
静态变量可以通过【类名.变量名】直接访问，也可以通过【实例.变量名】访问（不过，不推荐，因为容易混淆）。
因为所有线程共用同一个静态变量，多线程同时修改会出现并发问题，需要加锁保证线程安全。
因为实例变量和方法依赖具体的实例，静态方法调用时可能还没new对象，所以，静态方法只能直接访问静态变量和静态方法，不能直接访问实例变量和实例方法。
this 代表当前实例，静态方法属于类，调用时可能还没创建实例，this 根本不存在，所以，静态方法不能用 this。
静态内部类只能直接访问外部类的静态变量和静态方法，不能直接访问实例变量和实例方法。

【面试真题拆解】你知道ThreadLocal是什么吗

Sat, 21 Mar 2026 17:34:29 +0000

ThreadLocal 是线程专属的本地变量，它的设计是给每个线程创建一份独立的变量副本，线程之间完全不共享数据，天然实现线程隔离，全程无锁竞争，性能远高于加锁保证线程安全的方案。

每个 Thread 内部都有一个专属的成员变量 ThreadLocalMap（不是 ThreadLocal 的！），Key 是 ThreadLocal 实例本身（弱引用），Value 是存的变量（强引用）。

官话太多，直接上例子。

以用户上下文传递举个例子

/**
 * 用户上下文工具类
 * 用ThreadLocal存当前登录用户的ID，避免层层传参
 */
public class UserContextHolder {
    // 定义ThreadLocal，存用户ID
    private static final ThreadLocal<Long> USER_ID_THREAD_LOCAL = new ThreadLocal<>();

    /**
     * 设置用户ID
     */
    public static void setUserId(Long userId) {
        USER_ID_THREAD_LOCAL.set(userId);
    }

    /**
     * 获取用户ID
     */
    public static Long getUserId() {
        return USER_ID_THREAD_LOCAL.get();
    }

    /**
     * 必须手动调用！清理ThreadLocal，防止内存泄漏
     */
    public static void clear() {
        USER_ID_THREAD_LOCAL.remove();
    }
}

和加锁保证线程安全的区别

对比项	加锁	ThreadLocal
思想	多线程排队用同一个变量，保证同一时间只有一个线程能访问	每个线程用自己的专属变量，完全不共享
性能	有锁竞争，高并发下性能差	无锁竞争，性能高
适用场景	多线程必须共享同一个变量的场景（比如共享计数器、共享资源修改）	每个线程需要独立变量副本的场景（比如用户上下文、SimpleDateFormat 线程安全）

小贴士

很多人以为ThreadLocalMap的Key是“线程ID”，其实Key是ThreadLocal实例本身，而不是线程ID。

一个线程可以有多个ThreadLocal实例，每个实例对应一个Value，存到同一个ThreadLocalMap里，Key不同，互不干扰。

ThreadLocal内存泄漏问题

Java中的4种引用强度

强引用

我们平时写的 Object obj = new Object() 就是强引用，只要强引用还在，GC就不会回收这个对象。

软引用

用 SoftReference 包装的引用，只有当内存不够用的时候，GC 才会回收这个对象。

弱引用

用 WeakReference 包装的引用，只要GC一运行，不管内存够不够，都会回收这个对象。

虚引用

用 PhantomReference 包装的引用，完全不影响对象的生命周期，只是用来在对象被 GC 回收前收到一个通知，做一些收尾工作。

ThreadLocalMap的Entry结构

ThreadLocalMap的Entry是继承自WeakReference的，结构如下：

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    Entry(ThreadLocal<?> k, Object v) {
        super(k); // Key是弱引用
        value = v; // Value是强引用
    }
}

假设创建了一个 ThreadLocal 实例，有外部强引用指向它，同时把它作为 Key 存到了线程的 ThreadLocalMap 里；

当用完 ThreadLocal 后，没有手动 remove，而且外部的强引用也没了（比如 threadLocal = null），因为 Key 是弱引用，GC 一运行，Key 就被回收了，变成了 null。

但是， Value 是强引用，只要线程还活着，Value 就不会被 GC 回收，这就导致了内存泄漏。

更严重的还有，如果用了线程池，线程会被长期复用，不仅内存泄漏，还会导致用户信息串号、数据错误等严重的业务问题。

怎么避免内存泄漏

使用完ThreadLocal后，手动调用 remove() 方法。

举个例子，在Spring Boot的拦截器里：

@Component
public class UserInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        // 从Token里解析出用户ID，存到ThreadLocal
        Long userId = parseUserIdFromToken(request.getHeader("Authorization"));
        UserContextHolder.setUserId(userId);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        // 在这里清理，不管请求成功失败，都要清理。
        UserContextHolder.clear();
    }
}

【面试真题拆解】被问懵的计算机网络7层_5层_4层模型

Sat, 21 Mar 2026 09:04:13 +0000

好几次面试都被问了计算机网络模型，一次是让我讲讲7层模型，还有让我讲讲5层模型，4层模型的。

这群面试官完全不按套路出牌，昨天刚问完 7 层模型，今天就换成了 4 层模型。

我当场脑子一片空白，支支吾吾说不清楚，直接就凉了。

首先，为什么会有三个版本？

且看：

7层模型（OSI参考模型）

这是国际标准化组织定的理论学术标准，是网络分层的“祖宗”，但实际互联网几乎不用。

4层模型（TCP/IP模型）

互联网实际在用的工业落地标准，我们现在上网、写代码用的HTTP、TCP、IP，全是基于这个模型跑的，是真正“干活”的模型。

5层模型（教材简化模型）

国内计算机教材最常用的简化教学版，把4层模型的最底层拆成了2层，方便理解学习。

面试的时候，不管面试官问哪个模型，可以先把下面这张对应关系表讲出来，这样就能把三个模型的边界划清楚，也不容易搞混。

7 层 OSI 参考模型	5 层教材简化模型	4 层 TCP/IP 工业模型	作用
应用层	应用层	应用层	给用户/应用提供服务，比如浏览器、APP
表示层	（合并到应用层）	（合并到应用层）	数据加密、格式转换、统一编码
会话层	（合并到应用层）	（合并到应用层）	建立和维持应用之间的会话连接
传输层	传输层	传输层	给数据标端口，控制端到端的传输方式
网络层	网络层	网际层	给数据标 IP，规划端到端的传输路线
数据链路层	数据链路层	网络接口层	给数据标 MAC 地址，相邻节点之间的传输
物理层	物理层	（合并到网络接口层）	电信号、光信号的物理传输

7层OSI参考模型

7. 应用层

应用层主要是给用户/应用提供可操作的服务，定义数据的业务含义。

统称为消息/报文 (Message)。

我们写代码天天接触的HTTP、HTTPS、DNS、FTP、WebSocket、RPC协议，全在这一层。

浏览器发请求、APP调接口，都是在应用层完成的。

6. 表示层

表示层主要是统一数据格式，保证收发双方能看懂对方的数据，核心负责数据的加密解密、格式转换、压缩解压、编码统一。

理论上 OSI 模型把加密解密放在表示层；

但在实际 TCP/IP 模型中，TLS/SSL 属于应用层实现，工作在应用层与传输层之间。

5. 会话层

会话层主要是管理应用之间的会话，保证数据不会串线。

负责建立、维持、有序断开应用之间的会话连接，提供会话同步、全双工 / 半双工切换等管理能力；

该层仅存在于 OSI 理论模型中，实际 TCP/IP 体系中无独立对应层，相关会话逻辑由应用层 + 传输层共同实现。

4. 传输层

传输层是端到端的传输控制，保证数据能准确送到对应的应用程序。

数据单位称为段 (Segment)。

TCP（可靠传输）、UDP（不可靠传输），还有端口号（HTTP的80端口、HTTPS的443端口），都在这一层。

3. 网络层

作用是网络寻址和路由选择，保证数据能从源主机送到目标主机。

数据单位称为包 (Packet) 或分组。

IP 协议（IPv4/IPv6）、ARP（IP 转 MAC 地址）、ICMP（ping/tracert 命令）、OSPF/RIP 路由协议，都在这一层。

2. 数据链路层

相邻节点之间的可靠传输，负责成帧 (Framing)、差错检测和流量控制。

数据单位称为帧 (Frame)。
MAC地址、以太网协议、交换机转发，都在这一层。

给 IP 数据包加上 MAC 头部，标上源 MAC 和下一跳的 MAC 地址，保证相邻节点之间能准确传输。

1. 物理层

物理介质上的比特流传输。只负责传输0和1的比特流，不管数据是什么含义。

数据单位称为比特 (Bit)。

网线、光纤、网卡、集线器、电信号、光信号，都在这一层。

4层TCP/IP模型

OSI模型太理想化、太复杂，实际互联网落地的时候，做了两层合并，就成了现在真正在用的4层模型：

应用层：合并了OSI的应用层+表示层+会话层
传输层：同OSI的传输层
网际层：同OSI的网络层
网络接口层：合并了OSI的数据链路层+物理层

我们现在上网、写代码的所有网络请求，全是跑在这个4层TCP/IP模型上的，是真正的工业标准。

5层教材简化模型

国内教材为了兼顾教学易懂性和底层逻辑完整性，以 OSI 7 层模型为基础做简化，保留应用层、传输层、网络层，同时将底层拆分为数据链路层 + 物理层，形成了教学通用的 5 层简化模型。

这个模型既保留了底层的物理传输逻辑，又简化了上层的复杂分层。

举个例子

在浏览器输入网址，到页面显示出来，经过了网络模型的哪些层？

(1)客户端发送请求（从上到下封装数据包）

应用层

浏览器解析网址，先通过 DNS 协议解析域名，拿到服务器的 IP 地址，再生成对应的 HTTP 请求。

传输层

先通过三次握手与服务器建立 TCP 连接，再给 HTTP 请求加上 TCP 头部，标上源端口和目标端口，完成传输层封装。

网络层

给TCP数据包加上IP头部，标上源IP和目标IP，路由器根据IP地址规划路由，找到服务器的网络地址。

数据链路层

给IP数据包加上MAC头部，标上源MAC和下一跳的MAC地址，交换机根据MAC地址完成相邻节点转发。

物理层

把数据包转换成电信号/光信号，通过网线、光纤、基站等物理介质，传输到目标服务器。

(2)服务器接收并处理请求（从下到上解析数据包）

服务器收到数据后，从下到上逐层解包：物理层➡️数据链路层➡️网络层➡️传输层➡️应用层，最终解析 HTTP 请求、执行业务逻辑并返回响应。

(3) 客户端渲染页面

浏览器收到响应后，解析HTML/CSS/JS，渲染页面并显示给用户。

每层对应的协议

层级名称	协议
应用层	HTTP、HTTPS、DNS、FTP、SMTP（邮件发送）、POP3/IMAP（邮件接收）、WebSocket、SSH、Dubbo 等 RPC 协议
传输层	TCP（可靠传输）、UDP（不可靠传输）
网络层	IPv4、IPv6、ARP（IP 转 MAC 地址）、ICMP（ping/tracert）、OSPF、RIP 等路由协议
数据链路层	以太网协议、PPP 点对点协议、VLAN 协议、MAC 地址规范
物理层	无专属网络协议，相关规范：网线、光纤、网卡、集线器、RJ45 接口

小贴士：

ARP 协议逻辑上属于网络层（核心为 IP 协议提供地址解析服务，是 TCP/IP 网际层的核心配套协议），仅从报文封装形式来看，它被直接封装在以太网帧中，因此也有观点认为它属于数据链路层。

【面试真题拆解】5秒内限10次HTTP接口访问，结合数据结构和算法说说你的思路

Fri, 20 Mar 2026 15:00:00 +0000

面试官问：

做Web项目的时候，会暴露出一些HTTP接口，我现在想对它进行限流，限制5秒内只能访问10次，结合数据结构和算法，看如何实现，说说你的思路

当时只说了个滑动窗口就没说其他的，然后就没有然后了。。。

首先，为什么要限流？

主要有以下三个原因：

防止恶意刷接口，比如爬虫爬数据、黑客DDoS攻击。
保护服务器不被压垮，比如一个接口挂了，拖垮整个服务。
保证核心业务的可用性，比如大促场景下，支付接口优先，对普通接口进行限流。

技术选型

方案	数据结构+算法	核心思想	优缺点	适用场景
固定窗口计数器	数组/Map + 时间戳	把时间分成固定的窗口，每个窗口内计数	简单易实现；有临界问题（比如4.9秒刷10次，5.1秒又刷10次，实际0.2秒内刷了20次）	对精度要求不高的场景
滑动窗口计数器	本地：LinkedList（双向链表）分布式：Redis ZSet（有序集合） + 时间戳	窗口是“滑动”的，只保留当前窗口内的请求	解决了固定窗口的临界问题；本地版 LinkedList 删头加尾 O (1)，分布式版 ZSet 按时间范围操作高效；本地版不适合分布式集群	固定时间窗口内精确计数的场景
漏桶算法	队列 + 定时器	像漏桶一样，请求先存到队列里，然后匀速处理	可以削峰填谷；突发流量处理不了（秒杀时很多请求直接被拒）	对流量稳定性要求高的场景（比如消息队列）
令牌桶算法	队列 + 定时器	像令牌桶一样，匀速生成令牌，请求拿到令牌才能通过	可以削峰填谷，也可以处理突发流量	对流量稳定性和突发流量都有要求的场景（比如API网关）

滑动窗口计数器

滑动窗口的核心，是窗口不再是静止分段的，而是随当前时间连续移动、互相重叠的：

比如固定窗口，窗口是死的，0-5秒、5-10秒，边界固定不变。

而滑动窗口，窗口的右边界永远是当前请求的时间，左边界永远是当前时间 - 窗口大小，窗口会跟着每一次请求一直往前滑。

数据结构选型

本地：LinkedList（双向链表）

选择双向链表是因为我们需要频繁删除链表头部的过期时间戳，并且还需要频繁在链表尾部新增新的请求时间戳，而双向链表的删头、加尾操作时间复杂度都是O(1)，效率极高。

分布式：Redis ZSet（有序集合）

Web项目基本都是集群部署，本地计数器无法多实例同步，考虑用Redis实现。

选择Redis中的ZSet数据结构，ZSet的score字段可以存请求的时间戳，天然支持按时间范围排序。

实现逻辑

每次请求进来，执行 3 步：

删掉所有早于当前时间 - 窗口大小的请求
统计当前窗口内的请求数，超过 10 次直接拒绝
把当前请求的时间戳加入数据结构，放行请求

小贴士

令牌桶的令牌生成速度要合理

不能太快（等于没限流），也不能太慢（很多请求被拒），要根据业务场景调整。

Redis ZSet的过期时间要设置对

要设置成窗口大小+一点缓冲（比如1秒），防止数据提前过期，导致计数不准确。

【面试真题拆解】Spring事务机制

Fri, 20 Mar 2026 09:06:26 +0000

之前面试的时候还真的有一个面试官问过我：

什么是事务？

事务，说人话就是：

把多个数据库操作打包成一个“不可分割的整体”，要么全成功，要么全失败并回滚到最初状态，绝对不会出现“只做了一半”的情况。

以生活中最经典的银行转账举个例子那是再合适不过了。

且看：

A给B转100块钱，这一笔转账业务，其实是由两步独立的数据库操作组成的：

A的账户扣100块

B的账户加100块

这两步必须同时成功、一起生效。

如果A扣了钱B没收到，或者B收到了钱A没扣，那银行就乱套了。

事务的四大特性

用银行转账的例子加深理解：

特性	解释	银行转账例子
原子性（Atomicity）	要么全做，要么全不做，就像“原子”一样不可分割	A扣钱和B加钱必须同时成功，不能A扣了B没加
一致性（Consistency）	事务前后，数据要保持“一致”，总金额不变	转账前A有1000，B有0，总和是1000；转账后A有900，B有100，总和还是1000
隔离性（Isolation）	多个事务同时执行时，互相不干扰，就像“隔离开”一样	两个转账操作同时改A的账户，不能互相影响，不然钱就不对了
持久性（Durability）	事务提交后，数据就永久保存了，就算数据库挂了也不会丢	转账成功后，就算银行服务器断电重启，A和B的钱数也不会变

隔离级别

为什么要有隔离级别呢？

如果多个事务同时执行，没有隔离的话，会出现3个问题：

脏读

脏读就是读到了别人还没提交的数据。

比如A转给B100块，还没提交，B就查到自己多了100块，结果A回滚了，B白高兴一场。

不可重复读

不可重复读的意思是同一个事务里，两次读同一条数据的结果是不一样的。

比如A查自己有1000块，中间B转给了A100块提交了，A再查就变成1100了。

幻读

幻读就是同一个事务里，两次查的数量不一样。

比如A查账户里有10条记录，中间B插了一条提交了，A再查就变成11条了，就像“幻觉”一样。

这么看，不可重复读和幻读是由别的事务提交后导致的错误，而脏读是读到了别人还没提交的临时数据。

那不可重复读和幻读两者的区别在哪呢？

不可重复读是盯着一条记录看，发现这条记录的内容变了。

而幻读是盯着一堆记录数看，发现总数量变了。

类比一下就是不可重复读是你看自己的银行卡余额，钱数变了；而幻读是你数银行有多少张卡，卡的数量变了。

隔离级别	解决的问题	解释
读未提交（Read Uncommitted）	啥都解决不了	能读到别人没提交的数据，脏读、不可重复读、幻读都有，一般不用
读已提交（Read Committed）	脏读	只能读到别人提交后的数据，但会有不可重复读、幻读
可重复读（Repeatable Read）	脏读、不可重复读	Spring默认的隔离级别。同一个事务里，两次读同一个数据一样，但会有幻读（MySQL InnoDB用MVCC解决了幻读）
串行化（Serializable）	所有问题	事务一个接一个执行，就像“排队”一样，性能最差，一般不用

传播行为

传播行为就是：

当一个事务方法调用另一个事务方法时，这两个事务该怎么协作？是直接加入原事务？还是新建一个独立的事务？还是先挂起原事务，等新事务执行完再继续？

以下是3 个常用的传播行为:

传播行为	解释	适用场景
REQUIRED（默认）	有事务就加入，没有就新建一个事务	最常用，比如转账服务
REQUIRES_NEW	新建一个事务，挂起原事务，等新事务执行完再继续原事务	比如记录日志，不管主事务成功失败，日志都要记录
NESTED	嵌套事务，有一个保存点： 1. 子事务回滚：只回滚自己，不影响父事务和其他子事务 2. 父事务回滚：带着所有子事务一起回滚	系统批量发福利：某一个用户的福利发放失败，不影响其他用户；但整体回滚，所有用户的福利都会被收回

小贴士

Spring AOP 是基于代理的，@Transactional 只能用在 public 方法上，不然不生效。不管是 JDK 动态代理还是 CGLIB 代理，Spring 都只保证 public 方法的事务生效，非 public 的写了也白写。
内部调用不会走代理类，直接调用this.method()，所以，同一个类里方法调用，@Transactional不生效。
Spring默认只回滚非受检异常（RuntimeException、Error），受检异常（Exception）不回滚。如果要所有异常都回滚，需要在 @Transactional 里加rollbackFor = Exception.class。
MySQL的MyISAM引擎不支持事务，只有InnoDB支持。

【面试真题拆解】电商高并发场景下商品详情页系统设计

Wed, 18 Mar 2026 12:32:01 +0000

很多面试官早就对“Redis缓存、MySQL分库分表”这些东西形成免疫了，他们更想要听到的是一个完整的链路，比如从服务到数据、从接入到落地的全流程设计。

当时面试官问我：

一家电商公司，它主要是面向消费者的，公司的一些业务场景流量会很高，比如说展示商品的那个页面，它的流量就很高，假设现在由你来做这个系统，负责商品详情页的展示，你能从服务的层面，数据的层面等多个维度来设计一下，让它能够支持一个更高的查询能力。

场景梳理

业务背景
电商商品详情页，面对百万级QPS的高并发流量（比如大促、爆款商品）。

需求分析

性能：支持高并发查询，响应时间 < 100ms
一致性：商品价格、库存、标题修改后，能及时更新
高可用：服务挂了、Redis挂了，系统不崩
可扩展：新增商品、新增规格，能快速接入

关键数据
商品基本信息（标题、主图、详情图）、价格（实时/活动）、库存、规格参数、促销信息（优惠券/秒杀）、评价统计。

设计思路

以“多级缓存”为核心，配合“服务分层+数据分层+异步更新”，构建“读多写少”的高并发详情页系统。

系统架构

服务层面

采用前后端分离+网关层+服务分层架构：

层级	作用
CDN层	静态资源加速（图片、js、css、详情页HTML）
网关层	路由、限流、鉴权、接口聚合
API网关聚合层	聚合多个微服务接口（比如商品基础信息、价格、库存、评价），减少请求次数
商品服务层	核心业务逻辑（查商品、查库存、查价格）
数据服务层	专门做数据查询（缓存+数据库）

商品详情页是典型的读多写少场景，考虑服务层本地缓存 + 分布式缓存。

采用Caffeine作为服务层本地缓存，缓存极热点商品（比如爆款商品），避免每次请求都走Redis，

采用Redis作为分布式缓存，作为核心缓存层，缓存所有商品的详情数据。

调用流程：

先查本地缓存（Caffeine），如果命中就直接返回；

如果本地未命中，查 Redis，命中则写入本地缓存，返回；

如果Redis 未命中，查数据库，查到则写入 Redis + 本地缓存，返回。

数据层面

商品数据分为3类，不同类型用不同策略：

数据类型	例子	缓存策略
静态数据	商品标题、主图、详情图、规格参数	永久缓存（不过期），更新时主动删除
半动态数据	商品价格、促销信息（优惠券、满减）	短期缓存（5-10分钟），更新时主动删除
动态数据	库存（实时）、实时销量	单独缓存，库存用Redis原子操作；实时销量异步更新

缓存更新的原则：

为了避免高并发下的缓存不一致问题，采用的是先更新数据库，再删除缓存的方式。

高并发优化

1.热点数据预热

大促前，把热门商品（如销量TOP100）写入Redis和本地缓存。

限流+熔断+降级

对商品详情接口设置限流。

考虑使用服务熔断，当Redis/数据库不可用时，快速失败，避免系统雪崩。

或者考虑使用降级策略，当Redis挂了，降级到直接查数据库，如果数据库也挂了，降级返回默认商品信息。

页面静态化

对于完全静态的商品（比如虚拟商品或者不参与促销的商品），生成静态HTML页面，直接存到CDN，这样的话用户请求直接由CDN返回，不经过任何服务。

【面试真题拆解】高并发场景下“恶意登录设备识别”系统设计

Wed, 18 Mar 2026 10:41:34 +0000

这是面试遇到的一道场景题。

面试官问我：

有这么一个场景，现在有一个网站，这个网站访问的人非常多，在登录的时候有些坏人来这里捣乱，怎么去设计一个系统实现把这些坏人找到的逻辑。

条件说一下：

登录的时候你要的用户userid，时间，设备deviceid这些信息都有；

坏人的定义是：最近十分钟之内，一个设备上登录了大于等于5个user，我就认为这个是坏人。

场景梳理

输入信息：用户登录时的 userId（用户ID）、timestamp（登录时间戳）、deviceId（设备ID）；
坏人定义：最近10分钟（600秒）内，同一个deviceId上登录了≥5个不同的userId；
输出结果：标记该deviceId为“恶意设备”，后续可以做拦截、验证码、风控等处理。

实现方案

考虑用Redis ZSet实现滑动窗口。

为什么选Redis？

主要是因为：

单线程高性能，适合高并发场景
内存数据库，读写速度极快
支持丰富的数据结构（比如这次场景需要的ZSet）
支持过期时间，自动清理数据

为什么选ZSet？

ZSet（有序集合）是 Redis 中最适合做 “时间窗口、排行榜、去重 + 排序” 的数据结构。

它有以下几个特点：
Member（成员）唯一，Member 不能重复，天然去重；
每个 Member 对应一个 Score（分数），Score 是一个浮点数，用来排序；
ZSet 会自动按 Score 从小到大进行排序，如果Score 相同则按 Member 字典序排序。

ZSet 的底层是哈希表 + 跳表，哈希表保证 Member 唯一、O (1) 查找，跳表保证有序、O (log n) 范围查询。

数据模型

维度	说明
Key	`login:device:{deviceId}`（比如 `login:device:abc123`）
Value（ZSet Member）	`userId`（用户ID，保证唯一性，去重）
Score（ZSet Score）	`登录时间戳`（用于滑动窗口）

理一下整个流程

用户发起登录请求：携带 userId、deviceId、timestamp；
先查黑名单：如果已经是恶意设备，直接拦截；
写入登录记录到Redis ZSet：以 deviceId 为Key，userId 为Member，timestamp 为Score，写入ZSet；
清理过期数据：删除ZSet中Score < 当前时间 - 10分钟的元素；
统计最近10分钟内的不同userId数量：用 ZCard 命令统计ZSet的元素个数；
判断是否为坏人：如果数量≥5，标记该deviceId为恶意设备，存入Redis黑名单；
返回登录结果：如果是恶意设备，返回“请完成验证码”或“登录失败”；否则正常登录。

简化版的代码实现

用Spring Boot + RedisTemplate写一个简化版的实现，加深理解一下：

（1）先定义Redis Key的前缀和常量

public class RedisKeyConstants {
    // 设备登录记录Key前缀
    public static final String LOGIN_DEVICE_KEY_PREFIX = "login:device:";
    // 恶意设备黑名单Key前缀
    public static final String MALICIOUS_DEVICE_KEY_PREFIX = "malicious:device:";
    // 滑动窗口大小：10分钟（600秒）
    public static final int WINDOW_SIZE_SECONDS = 600;
    // 坏人阈值：≥5个不同userId
    public static final int MALICIOUS_THRESHOLD = 5;
    // 过期时间：10分钟
    public static final int EXPIRE_TIME_SECONDS = 600;
}

（2）服务实现

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;

@Service
public class LoginRiskControlService {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    /**
     * 检查是否为恶意设备
     * @param userId 用户ID
     * @param deviceId 设备ID
     * @return true-是恶意设备，false-正常设备
     */
    public boolean checkMaliciousDevice(String userId, String deviceId) {
        // 1. 构造Redis Key
        String loginKey = RedisKeyConstants.LOGIN_DEVICE_KEY_PREFIX + deviceId;
        String maliciousKey = RedisKeyConstants.MALICIOUS_DEVICE_KEY_PREFIX + deviceId;

        // 2. 先查黑名单：如果已经是恶意设备，直接返回true
        if (Boolean.TRUE.equals(redisTemplate.hasKey(maliciousKey))) {
            return true;
        }

        // 3. 获取当前时间戳（秒）
        long currentTime = System.currentTimeMillis() / 1000;
        // 计算窗口起始时间：当前时间 - 10分钟
        long windowStartTime = currentTime - RedisKeyConstants.WINDOW_SIZE_SECONDS;

        // 4. 写入当前登录记录到ZSet：Member=userId，Score=当前时间戳
        redisTemplate.opsForZSet().add(loginKey, userId, currentTime);

        // 5. 清理过期数据：删除Score < 窗口起始时间的元素
        redisTemplate.opsForZSet().removeRangeByScore(loginKey, 0, windowStartTime);

        // 6. 统计最近10分钟内的不同userId数量（ZSet的元素个数）
        Long count = redisTemplate.opsForZSet().zCard(loginKey);

        // 7. 设置Key的过期时间：10分钟（防止内存泄漏）
        redisTemplate.expire(loginKey, RedisKeyConstants.EXPIRE_TIME_SECONDS, TimeUnit.SECONDS);

        // 8. 判断是否为坏人：数量≥5
        if (count != null && count >= RedisKeyConstants.MALICIOUS_THRESHOLD) {
            // 标记为恶意设备，存入黑名单，过期时间可以设长一点（比如24小时）
            redisTemplate.opsForValue().set(maliciousKey, "1", 24, TimeUnit.HOURS);
            return true;
        }

        // 9. 正常设备，返回false
        return false;
    }
}

（3）在登录接口中调用

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/login")
public class LoginController {

    @Autowired
    private LoginRiskControlService riskControlService;

    @PostMapping
    public String login(String userId, String deviceId) {
        // 1. 先检查是否为恶意设备
        boolean isMalicious = riskControlService.checkMaliciousDevice(userId, deviceId);
        if (isMalicious) {
            return "登录失败：检测到异常设备，请完成验证码验证";
        }

        // 2. 正常登录逻辑（校验账号密码、生成Token等）
        // ...

        return "登录成功";
    }
}

高并发场景的优化

在访问量非常大的场景下，上面的代码肯定扛不住，所以还需要做一些优化。

1. 布隆过滤器快速过滤正常设备

如果每个登录请求都查Redis，Redis的压力会很大。

可以考虑用布隆过滤器先快速过滤：

在布隆过滤器里只存“潜在恶意设备”（比如最近10分钟内登录过≥3个userId的设备），登录时先查布隆过滤器，如果不在里面，直接放行，不查Redis；如果在里面，再查Redis确认。

2. 异步处理

如果Redis查询慢，会阻塞主登录流程，影响用户体验。

考虑把“写入ZSet、清理过期数据、统计数量、判断坏人”这些步骤用线程池或消息队列异步执行，这样的话主登录流程只做“账号密码校验、生成Token”，用户体验会更好一点。

小贴士：

异步会有极短的延迟，但是风控允许这种小误差。

3. 本地缓存+Redis双层缓存

如果恶意设备黑名单查询很频繁，每次都查Redis还是会有压力。

考虑用本地缓存（比如Caffeine）+ Redis 的双层缓存。

这样一来本地缓存存“最近1分钟内的恶意设备黑名单”，登录时先查本地缓存，命中直接返回，没命中再查Redis，查到后写入本地缓存。

小贴士：

本地缓存不能设 10 分钟，因为多实例部署时，本地缓存互不同步，会导致风控失效。

设 1 分钟既能减轻 Redis 压力，又能保证安全可控。

【面试真题拆解】Spring中的注解

Wed, 18 Mar 2026 08:53:48 +0000

面试官没有直接问我“@Autowired和@Resource的区别”这种题，而是：

先让我举几个Spring注解的例子，再问“Spring注解定义为什么都挺短，不会有大量代码”，直接考察你对注解本质和Spring AOP/IOC底层的理解。

举几个Spring注解的例子

1. IOC依赖注入类注解

注解	作用	区别
@Autowired	Spring原生注解，按类型（byType）自动注入依赖	优先byType，找不到唯一Bean时，会尝试按变量名（byName）匹配；可以配合 `@Qualifier` 指定Bean名称；可以用 `required=false` 允许依赖为空
@Qualifier	配合 `@Autowired` 使用，强制按名称（byName）注入依赖	当容器中有多个同类型Bean时，必须用它指定具体用哪个
@Resource	按名称（byName）优先注入，找不到再按类型（byType）匹配	JSR-250标准，跨框架兼容性好；可以用 `name` 属性显式指定Bean名称

2. IOC组件注册类注解

注解	作用
@Component	通用组件注册注解，把任意类标记为Spring容器的Bean
@Controller	`@Component` 的子类，专门标记Web控制器层的Bean
@Service	`@Component` 的子类，专门标记业务逻辑层的Bean
@Configuration	`@Component` 的子类，专门标记Java配置类，替代XML配置文件
@Repository	@Component 的子类，专门标记数据访问层的 Bean；还能把数据库的异常（如 SQLException）转换成 Spring 的 DataAccessException（非受检异常）

3. AOP切面类注解

横切关注点就是“和业务逻辑无关，但很多地方都要用的功能”，比如日志、事务、权限校验、性能监控这些。

注解	作用
@Aspect	把类标记为切面类
@Pointcut	定义切入点表达式，告诉Spring“哪些方法需要被增强”
@Before	前置通知：在目标方法执行之前执行增强逻辑
@After	后置通知：在目标方法执行之后（不管有没有异常）执行增强逻辑
@AfterReturning	返回通知：在目标方法正常返回之后执行增强逻辑
@AfterThrowing	异常通知：在目标方法抛出异常之后执行增强逻辑
@Around	环绕通知：最强大的通知，可以完全控制目标方法的执行（比如不执行目标方法、修改参数、修改返回值）

Lombok的常用注解

Lombok是一种代码简化工具，通过注解自动生成代码。

虽然不是Spring原生注解，但Lombok的注解是Java开发中经常会用到的。

注解	作用
@Slf4j	自动生成 SLF4J日志对象
@Data	自动生成 getter/setter、toString、equals、hashCode、无参构造器
@NoArgsConstructor	自动生成无参构造器
@AllArgsConstructor	自动生成全参构造器

Spring 注解定义为什么通常都挺短，不会有大量代码？

面试官这么问主要是想考察你对注解本质和Spring容器底层的理解。

先明确一下元数据（Metadata）的定义，元数据就是“描述数据的数据”，本身不是数据的内容，只是给数据打标签、加属性。

根本原因在于注解只是元数据标记，本身不包含任何逻辑。

举个Spring注解的例子，比如 @Transactional：

// @Transactional的核心定义（简化版，去掉了很多元注解和属性）
@Target({ElementType.METHOD, ElementType.TYPE}) // 元注解：标记这个注解能用在方法/类上
@Retention(RetentionPolicy.RUNTIME) // 元注解：标记这个注解保留到运行时
@Inherited // 元注解：标记这个注解可以被子类继承
@Documented // 元注解：标记这个注解会被生成到JavaDoc里
public @interface Transactional {
    // 只有属性，没有任何方法/逻辑！
    String value() default ""; // 事务管理器的名称
    Propagation propagation() default Propagation.REQUIRED; // 传播行为
    Isolation isolation() default Isolation.DEFAULT; // 隔离级别
    int timeout() default -1; // 超时时间
    boolean readOnly() default false; // 是否只读
}

可以看到@Transactional 的定义里只有属性，没有任何一行业务逻辑或容器逻辑。

它只是告诉Spring容器：“这个方法/类需要开启事务，传播行为是REQUIRED，隔离级别是DEFAULT…”，真正开启/提交/回滚事务的逻辑，全在Spring的事务管理器和AOP切面里。

除此之外，Spring注解的定义比较短，还有一个原因是Spring大量使用了元注解（Meta-Annotation）。

那什么是元注解呢？

元注解就是“标记注解的注解”，可以复用已有注解的功能，不用重复写代码。

比如上面的 @Transactional，它上面有@Target、@Retention、@Inherited、@Documented这4个元注解。

怎么自定义一个Spring注解？

简单来说有以下3步：

定义注解

用 @interface 定义，加上JDK原生元注解（至少需要 @Target 和 @Retention(RUNTIME)）；

编写后置处理器

实现 BeanPostProcessor 或 BeanFactoryPostProcessor 接口，或者用 AOP 切面（更适合方法级别的拦截，比如权限校验、记录执行时间），处理自定义注解的逻辑；

注册后置处理器

把自定义后置处理器交给Spring容器管理（比如用 @Component 标记）。

举个例子@AuthCheck：

@Target(ElementType.METHOD)
//规定这个标签能贴在哪里,ElementType.METHOD 意思是“只能贴在方法上面”。
@Retention(RetentionPolicy.RUNTIME)
//规定这个标签的有效期,RUNTIME的意思是“程序运行的时候，这个标签依然存在”
public @interface AuthCheck {

    /**
     * @interface 不是接口（interface），而是专门用来定义注解的语法。
     * String mustRole()：表示用这个标签时，
     * 你可以写上一个角色名，比如 @AuthCheck(mustRole = "admin")。
     * default ""：如果你只写了 @AuthCheck
     * 而没填角色，那默认值就是一个空字符串 ""
     * （表示不需要特定角色，只要登录就行，具体看你怎么实现业务逻辑）。
     *
     */
    String mustRole() default "";
}

【面试真题拆解】Java文件操作的异常类型与受检_非受检异常

Tue, 17 Mar 2026 21:09:31 +0000

以往面试的时候问Java异常好像背一背题就行，但是这个面试官水平还是很高的，换了一种问法，大概是这么问的：

Java中写了一个函数，打开了一个文件，读这个文件然后关闭，中间没有写try-catch，保存之后，编辑器自动在这个函数声明后面加了throws exception，你觉得这些exception会有哪些呢？

如果把这个函数进行修改，不读写文件，只进行简单的数据处理，这时保存之后，发现函数声明的后面没有throws这些异常了，在这种情况下是不是就不会抛出异常了？

有点懵了，完犊子。。。

主要有以下几点，掌握了应该问题不大：

文件操作的异常主要是IOException及其子类，属于受检异常，必须显式处理（要么 try-catch，要么 throws）；

简单数据处理的异常多是RuntimeException 及其子类（如空指针、数组越界），属于非受检异常，无需强制 throws 或 try-catch；

受检异常要求“编译时必须处理”，非受检异常是“运行时才可能出现”，编译器不强制要求。

文件操作会抛出哪些异常？

复现一下面试题里的场景：

写一个文件读写函数，没加 try-catch，编辑器自动加了 throws Exception。

import java.io.*;

public class FileReadExample {
    // 编辑器自动加了 throws Exception，因为里面有受检异常
    public void readFile(String filePath) throws Exception {
        // 1. 打开文件流
        FileInputStream fis = new FileInputStream(filePath);
        // 2. 读取文件内容
        byte[] buffer = new byte[1024];
        int len = fis.read(buffer);
        // 3. 关闭文件流
        fis.close();
    }
}

有以下几种文件操作中常见的异常

异常类型	触发场景
FileNotFoundException	文件路径不存在、文件是目录、没有读权限
IOException	读取文件时IO错误（如磁盘损坏、网络文件系统（NFS）的连接意外中断）
EOFException	读取到文件末尾仍尝试读取

小贴士：

FileNotFoundException 是 IOException 的子类，如果 throws IOException，也能覆盖 FileNotFoundException。

为什么简单数据处理不需要 `throws`？

面试题里的第二个场景：

把函数改成只做简单数据处理，编辑器就不加 throws 了。

复现一下这个场景：

public class SimpleDataProcessExample {
    // 编辑器不会加 throws，因为里面都是非受检异常
    public void processData(int[] arr, String str) {
        // 1. 数组越界：ArrayIndexOutOfBoundsException（非受检）
        int num = arr[10];
        // 2. 空指针：NullPointerException（非受检）
        int len = str.length();
        // 3. 非法参数：IllegalArgumentException（非受检）
        if (arr.length == 0) {
            throw new IllegalArgumentException("数组不能为空");
        }
    }
}

这里的主要原因是：

简单数据处理的异常都是 RuntimeException 的子类，是非受检异常，编辑器不会强制要求 throws 或 try-catch。

受检异常 vs 非受检异常

对比维度	受检异常（Checked Exception）	非受检异常（Unchecked Exception）
定义	编译时必须处理的异常，不处理编译不通过	运行时才可能出现的异常，编译器不强制要求处理
所属类	`Exception` 及其子类（除了 `RuntimeException` 及其子类）	`RuntimeException` 及其子类、`Error` 及其子类
典型例子	`IOException`、`FileNotFoundException`	`NullPointerException`、`ArrayIndexOutOfBoundsException`、`IllegalArgumentException`
处理要求	必须 `try-catch` 或 `throws`	可以不处理，也可以处理
设计目的	提醒开发者“这里可能有外部不可控的错误，必须处理”	提醒开发者“这里有代码逻辑错误，需要修复代码”

实际开发中，文件操作的异常怎么处理？

不要直接 throws Exception，推荐显式抛出具体异常（如 throws IOException）或者 try-catch 处理，记录日志并给出友好提示。

举个例子：

public void readFile(String filePath) {
    FileInputStream fis = null;
    try {
        fis = new FileInputStream(filePath);
        byte[] buffer = new byte[1024];
        int len = fis.read(buffer);
    } catch (FileNotFoundException e) {
        System.err.println("文件不存在：" + filePath);
        e.printStackTrace();
    } catch (IOException e) {
        System.err.println("文件读取失败");
        e.printStackTrace();
    } finally {
        // 必须在 finally 里关闭流，防止内存泄漏
        if (fis != null) {
            try {
                fis.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

前后端分离+微服务架构下的用户认证

Tue, 17 Mar 2026 19:38:35 +0000

先明确一些核心组件：

组件	作用
前端	页面展示、用户交互、存储Token
API网关	统一入口、路由转发、Token校验
认证中心	用户登录验证、生成/刷新Token
微服务	处理业务逻辑、获取用户信息
数据库	存储用户账号密码、权限信息

当时面试官跟我说，你可以从前端打开一个页面开始讲。

那我们就举个例子：

以用户打开一个电商网站首页➡️跳转登录➡️输入账号密码登录➡️携带Token请求商品列表为例，说一下这个完整的流程。

1.前端打开页面，检查本地是否有Token

用户在浏览器输入 https://www.example.com，前端代码首先检查本地存储中是否存在有效的Token。

2.没有Token，前端跳转登录页，用户输入账号密码

如果本地没有Token，前端路由跳转到 /login 登录页，用户输入账号和密码，点击【登录】按钮。

3.前端发送登录请求到API网关

前端将账号密码封装成POST请求，发送到API网关。

需要注意的是：前端不直接请求认证中心，所有请求都走网关统一入口。

4.API网关转发登录请求到认证中心

API网关收到 /auth/login 请求，根据路由规则，将请求转发到认证中心服务。

5.认证中心验证用户信息，生成JWT Token

认证中心做以下3件事：

从数据库查询用户信息，验证账号密码是否正确；
验证通过后，生成 JWT Token（分为 Access Token 和 Refresh Token）；
将 Token 返回给前端。

那什么是JWT呢？

JWT（JSON Web Token）是一种无状态的Token，由三部分组成，用 . 分隔：

Header：头部，存算法和类型；
Payload：载荷，存用户信息（比如userId、username、过期时间）；
Signature：签名，用密钥对Header和Payload签名，防止Token被篡改。

6.前端收到Token，存储到本地

前端收到认证中心返回的 access_token 和 refresh_token，存到本地存储中。

7.前端携带Token请求业务接口

用户登录成功后，前端请求商品列表接口，在请求头 Authorization 中携带 Bearer Token。

Bearer 这个单词的意思是“持票人”、“持有者”。

Bearer Token 就是：“谁持有这个 Token，谁就是合法的访问者，服务器就认谁”。

8.API网关校验Token

API网关收到 /product/list 请求，通过全局过滤器校验Token的有效性：

从请求头 Authorization 中取出Token；
验证Token的签名是否正确；
验证Token是否过期；
校验通过后，将用户信息（比如userId）放入请求头，转发给微服务；
如果校验失败，直接返回401未授权。

9.微服务获取用户信息，处理业务逻辑

微服务（比如商品服务）收到网关转发的请求，从请求头 X-User-Id 中取出userId，处理业务逻辑（比如查询该用户的商品列表）。

10.Token过期，前端用Refresh Token刷新

Access Token有效期比较短（比如只有2小时），过期后前端请求会收到401；

此时前端不用让用户重新登录，而是用Refresh Token去认证中心刷新Access Token。

【面试真题拆解】Java锁机制：synchronized、ReentrantLock、锁升级、可重入锁

Tue, 17 Mar 2026 13:23:22 +0000

一句话速通：

Java 锁机制核心是 synchronized 和 ReentrantLock，两者都是可重入锁；

JDK 1.6+ 后 synchronized 引入锁升级（无锁➡️偏向锁➡️轻量级锁➡️重量级锁），性能大幅提升；

简单场景优先用 synchronized，需要高级功能（比如可中断、可超时、公平锁）时用 ReentrantLock。

为什么需要锁？

在并发场景下，多个线程同时修改同一个共享变量，会出现线程安全问题。

举个例子说明一下：

public class UnsafeCounter {
    private int count = 0;

    public void increment() {
        count++; // 这行代码不是原子操作！
    }

    public int getCount() {
        return count;
    }
}

如果1000个线程同时调用 increment()，最终 count 的值很可能小于1000。

因为 count++ 不是原子操作，它分为读取count、count+1、写回count三步，多线程同时执行会互相覆盖。

锁的作用就是把这段代码加锁，让同一时间只有一个线程能执行，从而保证操作的原子性。

synchronized

synchronized 是JVM内置的关键字，不需要手动释放锁。

用法	锁的对象	示例
锁实例方法	锁当前对象 `this`	`public synchronized void increment()`
锁静态方法	锁当前类的 `Class` 对象	`public static synchronized void increment()`
锁代码块	锁指定的对象	`synchronized (lock) { ... }`

可以用synchronized给之前的例子上锁：

public class SafeCounter {
    private int count = 0;

    // 锁实例方法：同一时间只有一个线程能执行
    public synchronized void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

ReentrantLock

ReentrantLock 是 java.util.concurrent（JUC）包下的锁，是基于代码实现的锁，比 synchronized 更灵活，但需要手动释放锁。

也可以用ReentrantLock给之前的例子上锁：

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockCounter {
    private int count = 0;
    // 创建 ReentrantLock 实例
    private ReentrantLock lock = new ReentrantLock();

    public void increment() {
        lock.lock(); // 加锁
        try {
            count++;
        } finally {
            lock.unlock(); // 必须在 finally 里释放锁，防止死锁
        }
    }

    public int getCount() {
        return count;
    }
}

ReentrantLock 有3个 synchronized 没有的功能：

功能	说明	示例
可中断	线程在等待锁的过程中，可以被中断，停止等待	`lock.lockInterruptibly()`
可超时	尝试获取锁，等待一段时间后如果还没拿到，就放弃	`lock.tryLock(1, TimeUnit.SECONDS)`
公平锁	按线程请求锁的顺序分配锁（先来先得），默认是非公平锁	`new ReentrantLock(true)`

可重入锁

synchronized 和 ReentrantLock 都是可重入锁。

那什么是可重入呢？

可重入的意思就是同一个线程，可以多次获取同一把锁，不会被自己阻塞。

那又为什么需要可重入呢？

举个递归调用的例子：

public class ReentrantExample {
    //  synchronized 是可重入的
    public synchronized void methodA() {
        System.out.println("执行 methodA");
        methodB(); // 调用 methodB，methodB 也需要同一把锁
    }

    public synchronized void methodB() {
        System.out.println("执行 methodB");
    }

    public static void main(String[] args) {
        ReentrantExample example = new ReentrantExample();
        example.methodA();
    }
}

如果锁是不可重入的，那么线程在执行 methodA() 时已经拿到了锁，调用 methodB() 时会因为拿不到锁而被自己阻塞，导致死锁。

synchronized 的锁升级

在 JDK 1.6 之前，synchronized 是重量级锁，性能很差；

JDK 1.6 之后，引入了锁升级机制，提升了 synchronized 的性能。

锁升级的意思是：

随着多线程竞争的加剧，锁会从【无锁】➡️【偏向锁】➡️【轻量级锁】➡️【重量级锁】逐步升级，而且升级是单向的，只能升不能降。

Java对象在内存中分为3部分：

对象头、实例数据、对齐填充，其中对象头里的 Mark Word 会记录锁的状态。

而synchronized 的锁是存放在【对象头】里的。

Mark Word 的结构（32 位 JVM）：

锁状态	25位	4位	1位（是否偏向锁）	2位（锁标志位）
无锁	对象的哈希码	分代年龄	0	01
偏向锁	偏向线程ID	分代年龄	1	01
轻量级锁	指向栈中锁记录的指针			00
重量级锁	指向重量级锁（monitor）的指针			10

锁升级的四个阶段

1. 无锁

没有线程竞争锁，对象处于无锁状态。

2. 偏向锁

只有一个线程多次获取同一把锁，没有其他线程竞争。
第一个线程获取锁时，会在对象头的 Mark Word 里记录【偏向线程ID】，这个线程以后再次获取锁时，只需要检查偏向线程ID是不是自己，如果是，直接获取锁。
当有第二个线程来竞争这把锁时，偏向锁会撤销，升级为轻量级锁。

3. 轻量级锁

多个线程交替获取锁，但是竞争不太激烈（比如线程A获取锁，执行完释放了，线程B再获取）。

线程在自己的栈帧里创建一个锁记录（Lock Record），用 CAS（Compare And Swap，比较并交换）操作，尝试把对象头的 Mark Word 替换成指向自己栈中锁记录的指针。

如果 CAS 成功，就获取到了轻量级锁。

当有多个线程同时竞争锁，CAS 失败多次，就会升级为重量级锁。

4. 重量级锁

多个线程同时竞争锁，竞争激烈。
锁升级为重量级锁后，对象头的 Mark Word 会指向一个monitor（监视器）对象。

没有获取到锁的线程会进入阻塞队列，被操作系统挂起，等待持有锁的线程释放锁后唤醒。

【面试真题拆解】Java锁机制：synchronized、ReentrantLock、锁升级、可重入锁

Tue, 17 Mar 2026 13:23:22 +0000

一句话速通：

Java 锁机制核心是 synchronized 和 ReentrantLock，两者都是可重入锁；

JDK 1.6+ 后 synchronized 引入锁升级（无锁➡️偏向锁➡️轻量级锁➡️重量级锁），性能大幅提升；

简单场景优先用 synchronized，需要高级功能（比如可中断、可超时、公平锁）时用 ReentrantLock。

为什么需要锁？

在并发场景下，多个线程同时修改同一个共享变量，会出现线程安全问题。

举个例子说明一下：

public class UnsafeCounter {
    private int count = 0;

    public void increment() {
        count++; // 这行代码不是原子操作！
    }

    public int getCount() {
        return count;
    }
}

如果1000个线程同时调用 increment()，最终 count 的值很可能小于1000。

因为 count++ 不是原子操作，它分为读取count、count+1、写回count三步，多线程同时执行会互相覆盖。

锁的作用就是把这段代码加锁，让同一时间只有一个线程能执行，从而保证操作的原子性。

synchronized

synchronized 是JVM内置的关键字，不需要手动释放锁。

用法	锁的对象	示例
锁实例方法	锁当前对象 `this`	`public synchronized void increment()`
锁静态方法	锁当前类的 `Class` 对象	`public static synchronized void increment()`
锁代码块	锁指定的对象	`synchronized (lock) { ... }`

可以用synchronized给之前的例子上锁：

public class SafeCounter {
    private int count = 0;

    // 锁实例方法：同一时间只有一个线程能执行
    public synchronized void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

ReentrantLock

ReentrantLock 是 java.util.concurrent（JUC）包下的锁，是基于代码实现的锁，比 synchronized 更灵活，但需要手动释放锁。

也可以用ReentrantLock给之前的例子上锁：

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockCounter {
    private int count = 0;
    // 创建 ReentrantLock 实例
    private ReentrantLock lock = new ReentrantLock();

    public void increment() {
        lock.lock(); // 加锁
        try {
            count++;
        } finally {
            lock.unlock(); // 必须在 finally 里释放锁，防止死锁
        }
    }

    public int getCount() {
        return count;
    }
}

ReentrantLock 有3个 synchronized 没有的功能：

功能	说明	示例
可中断	线程在等待锁的过程中，可以被中断，停止等待	`lock.lockInterruptibly()`
可超时	尝试获取锁，等待一段时间后如果还没拿到，就放弃	`lock.tryLock(1, TimeUnit.SECONDS)`
公平锁	按线程请求锁的顺序分配锁（先来先得），默认是非公平锁	`new ReentrantLock(true)`

可重入锁

synchronized 和 ReentrantLock 都是可重入锁。

那什么是可重入呢？

可重入的意思就是同一个线程，可以多次获取同一把锁，不会被自己阻塞。

那又为什么需要可重入呢？

举个递归调用的例子：

public class ReentrantExample {
    //  synchronized 是可重入的
    public synchronized void methodA() {
        System.out.println("执行 methodA");
        methodB(); // 调用 methodB，methodB 也需要同一把锁
    }

    public synchronized void methodB() {
        System.out.println("执行 methodB");
    }

    public static void main(String[] args) {
        ReentrantExample example = new ReentrantExample();
        example.methodA();
    }
}

如果锁是不可重入的，那么线程在执行 methodA() 时已经拿到了锁，调用 methodB() 时会因为拿不到锁而被自己阻塞，导致死锁。

synchronized 的锁升级

在 JDK 1.6 之前，synchronized 是重量级锁，性能很差；

JDK 1.6 之后，引入了锁升级机制，提升了 synchronized 的性能。

锁升级的意思是：

随着多线程竞争的加剧，锁会从【无锁】➡️【偏向锁】➡️【轻量级锁】➡️【重量级锁】逐步升级，而且升级是单向的，只能升不能降。

Java对象在内存中分为3部分：

对象头、实例数据、对齐填充，其中对象头里的 Mark Word 会记录锁的状态。

而synchronized 的锁是存放在【对象头】里的。

Mark Word 的结构（32 位 JVM）：

锁状态	25位	4位	1位（是否偏向锁）	2位（锁标志位）
无锁	对象的哈希码	分代年龄	0	01
偏向锁	偏向线程ID	分代年龄	1	01
轻量级锁	指向栈中锁记录的指针			00
重量级锁	指向重量级锁（monitor）的指针			10

锁升级的四个阶段

1. 无锁

没有线程竞争锁，对象处于无锁状态。

2. 偏向锁

3. 轻量级锁

多个线程交替获取锁，但是竞争不太激烈（比如线程A获取锁，执行完释放了，线程B再获取）。

如果 CAS 成功，就获取到了轻量级锁。

当有多个线程同时竞争锁，CAS 失败多次，就会升级为重量级锁。

4. 重量级锁

多个线程同时竞争锁，竞争激烈。
锁升级为重量级锁后，对象头的 Mark Word 会指向一个monitor（监视器）对象。

没有获取到锁的线程会进入阻塞队列，被操作系统挂起，等待持有锁的线程释放锁后唤醒。

【面试真题拆解】Redis的8种内存淘汰策略

Mon, 16 Mar 2026 22:54:44 +0000

Redis 内存淘汰策略共 8 种，分两大类：不淘汰和淘汰数据；

纯缓存场景优先选 allkeys-lru，混合场景选 volatile-lru，数据不能丢的话选 noeviction。

`maxmemory` 参数

只有设置了 maxmemory（Redis 最大内存限制），内存淘汰策略才会生效。

设置 `maxmemory`的两种方式

配置文件 redis.conf：

1
2

# 限制 Redis 最大使用 1GB 内存
maxmemory 1gb

命令行动态设置（重启后会失效）：

`1`	`127.0.0.1:6379> CONFIG SET maxmemory 1gb`

Redis 的8种内存淘汰策略

可以分为两大类：

大类	策略名称	含义
不淘汰数据	`noeviction`	内存满了，新写入直接报错，不淘汰任何数据
淘汰过期键	`volatile-lru`	淘汰设置了过期时间的键中，最近最少使用的
	`volatile-lfu`	淘汰设置了过期时间的键中，最不经常使用的
	`volatile-ttl`	淘汰设置了过期时间的键中，即将过期的
	`volatile-random`	随机淘汰设置了过期时间的键
淘汰所有键	`allkeys-lru`	淘汰所有键中，最近最少使用的
	`allkeys-lfu`	淘汰所有键中，最不经常使用的
	`allkeys-random`	随机淘汰所有键

1. `noeviction`

当内存满了，新写入的请求（比如 SET、LPUSH）会直接报错 (error) OOM command not allowed when used memory > 'maxmemory'，不淘汰任何数据。

适用于数据绝对不能丢，且有完善的内存监控和扩容机制（比如金融级核心数据）的场景。

2. 淘汰过期键的4种策略

这类策略只淘汰设置了 expire 过期时间的键，不会碰永久键，适合“缓存+持久化”混合的场景（比如永久键存重要数据，过期键存缓存）。

`volatile-lru`

LRU = Least Recently Used（最近最少使用）。

在设置了过期时间的键中，淘汰最久没被访问过的键。

比如缓存场景，往往会希望保留“最近刚用过的热数据”。

`volatile-lfu`

LFU = Least Frequently Used（最不经常使用）。

在设置了过期时间的键中，淘汰访问次数最少的键。

`volatile-ttl`

TTL = Time To Live（剩余生存时间）。

在设置了过期时间的键中，淘汰剩余时间最短、即将过期的键。

`volatile-random`

在设置了过期时间的键中，随机淘汰一个。

3. 淘汰所有键的3种策略

这类策略不管键有没有设置过期时间，都会淘汰，适合纯缓存场景（所有数据都是缓存，丢了也没关系，可以从数据库重新加载）。

`allkeys-lru`

在所有键中，淘汰最近最少使用的键。

比较适合电商商品缓存、用户Session缓存这些纯缓存场景。

`allkeys-lfu`

在所有键中，淘汰访问次数最少的键。

`allkeys-random`

在所有键中，随机淘汰一个。

LRU vs LFU，到底有啥区别？

对比维度	LRU（最近最少使用）	LFU（最不经常使用）
核心依据	看最近多久没被访问	看访问次数多少
优点	实现简单，符合“热数据最近常用”的直觉	更精准，能识别“真正的热数据”（比如某个键虽然最近没被访问，但总访问次数极高）
缺点	可能误删“偶尔访问一次的冷数据，但其实总访问次数很高”	实现复杂，需要额外空间记录访问次数

举个例子

假设键A昨天被访问100次，今天没被访问；

键B今天被访问1次。

因为最近没被访问，所以LRU会删键A。

但是，因为总访问次数只有1次，所以LFU会删键B。

【面试真题拆解】Java字节流、字符流

Mon, 16 Mar 2026 10:00:59 +0000

Java IO流的分类

Java IO流主要从两个维度分类：

分类维度	分类结果	说明
按数据流向分	输入流（Input）	从磁盘/网络/内存「读」数据到程序
	输出流（Output）	从程序「写」数据到磁盘/网络/内存
按处理单元分	字节流（Byte Stream）	以「字节（byte）」为单位处理数据，是万能流
	字符流（Character Stream）	以「字符（char）」为单位处理数据，专门处理文本

字节流

什么是字节流？

计算机里所有数据（图片、视频、音频、文本、PDF）本质上都是字节（0和1的组合），所以字节流是万能流，可以处理任何类型的数据。

字节流的核心类

字节流的抽象基类是 InputStream（输入流）和 OutputStream（输出流），开发中最常用的是它们的子类：

类名	作用
`FileInputStream`	从文件中读取字节
`FileOutputStream`	向文件中写入字节
`BufferedInputStream`	带缓冲的字节输入流，提升读性能
`BufferedOutputStream`	带缓冲的字节输出流，提升写性能

举个例子

字节流典型的应用——复制非文本文件（图片、视频、PDF）

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;

public class ByteStreamExample {
    public static void main(String[] args) {
        // 源文件路径（一张图片）
        String srcPath = "C:/test/photo.jpg";
        // 目标文件路径
        String destPath = "C:/test/photo_copy.jpg";

        // 用try-with-resources自动关闭流，避免内存泄漏
        try (
            // 1. 创建文件字节输入流：从源文件读字节
            FileInputStream fis = new FileInputStream(srcPath);
            // 2. 创建文件字节输出流：向目标文件写字节
            FileOutputStream fos = new FileOutputStream(destPath)
        ) {
            // 3. 定义一个字节数组作为缓冲区（一次读1024字节，即1KB，提升性能）
            byte[] buffer = new byte[1024];
            int len; // 记录每次实际读到的字节数

            // 4. 循环读写：fis.read(buffer)返回-1表示读到文件末尾
            while ((len = fis.read(buffer)) != -1) {
                // 只写实际读到的len个字节，避免最后一次写多余的空字节
                fos.write(buffer, 0, len);
            }
            System.out.println("图片复制成功！");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

字符流

什么是字符流？

字符流是专门处理文本数据的流，它以【字符】为单位处理数据，内部会自动处理编码转换（比如把UTF-8编码的字节转成Java的char字符）。

为什么不用字节流处理文本？

因为中文等非ASCII字符占多个字节（比如UTF-8编码的中文占3个字节）。

如果用字节流读，可能会把一个汉字的3个字节截断，从而导致乱码；

而字符流会自动识别编码，按字符读取，不会乱码。

字符流的核心类

字符流的抽象基类是 Reader（输入流）和 Writer（输出流），开发中最常用的是它们的子类：

类名	作用
`FileReader`	从文件中读取字符
`FileWriter`	向文件中写入字符
`BufferedReader`	带缓冲的字符输入流
`BufferedWriter`	带缓冲的字符输出流
`InputStreamReader`	转换流：字节流转字符流
`OutputStreamWriter`	转换流：字符流转字节流

举个例子

BufferedReader的readLine()方法可以按行读取文本，非常方便。

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.nio.charset.StandardCharsets;

public class CharacterStreamExample {
    public static void main(String[] args) {
        String filePath = "C:/test/中文文章.txt";

        // 用转换流InputStreamReader，显式指定UTF-8编码，避免乱码
        try (
            // 1. 先创建字节输入流
            FileInputStream fis = new FileInputStream(filePath);
            // 2. 用转换流把字节流转成字符流，显式指定UTF-8编码
            InputStreamReader isr = new InputStreamReader(fis, StandardCharsets.UTF_8);
            // 3. 用缓冲流包装，提升性能，且有readLine()方法
            BufferedReader br = new BufferedReader(isr)
        ) {
            String line;
            int lineNum = 1;
            // readLine()返回null表示读到文件末尾
            while ((line = br.readLine()) != null) {
                System.out.println("第" + lineNum + "行：" + line);
                lineNum++;
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}