八股 on Coder_Studio

Spring Boot + Vue 前后端联调踩坑记录

Fri, 03 Apr 2026 18:24:30 +0000

别再搞混了！Redis、Jedis、Lettuce、Spring Data Redis、Redisson、Spring Session Redis 一次讲透

Wed, 01 Apr 2026 19:17:35 +0000

一篇搞懂：Java包名、Maven artifactId、Spring application.name到底有啥区别？

Fri, 27 Mar 2026 21:33:09 +0000

项目文件夹叫codeedge-backend，Java包名是codeedgebackend，Maven的artifactId是codeedge-backend，Spring配置里还有个spring.application.name叫codeedge-backend。

这几个到底有啥区别？必须要对上吗？

其实，这几个是完全不同维度、不同作用、没有任何强制绑定关系的配置，给谁用、管什么、能不能乱改，差别还是挺大的。

我就用 codeedge-backend 项目当例子，先从最核心、最容易踩语法坑的 Java 包名说起。

Java包名 `com.codeedgexu.codeedgebackend`

这是Java语言强制规范的代码组织方式，是给Java编译器、JVM、Spring Boot看的，用来唯一标识代码类，和项目功能强绑定。

作用

唯一标识代码类，避免重名冲突

你的controller、config、service这些类，全在com.codeedgexu.codeedgebackend这个包下面。

Java编译器靠【包名+类名】唯一确定一个类，比如你的启动类全限定名是com.codeedgexu.codeedgebackend.CodeEdgeBackendApplication，这个名字全局唯一，不会和别人的项目重名冲突。

决定Spring Boot的Bean扫描范围

Spring Boot启动的时候，默认只会扫描启动类所在的包以及它的子包。

比如你的启动类在com.codeedgexu.codeedgebackend下面，那它只会扫这个包下面的controller、service，把它们注册成Bean。

如果改了代码的包名，但启动类没跟着搬到新包，Spring 就扫不到新包里的 controller、service 这些类，导致这些类不会被注册成 Bean，项目启动失败。

小贴士

Java包名里，绝对不能用横杠-。

因为横杠在Java里是减号运算符，不能出现在包名、类名、变量名里，编译器会直接报错。

这也是为什么我文件夹名可以叫codeedge-backend，但包名必须写成codeedgebackend的根本原因——不是我不想写一样的，是Java语法不允许。

Java包名的所有部分必须全小写。

这是Java的行业通用规范，虽然语法允许大写，但不专业，且很多代码规范检查工具会报错。

Maven artifactId `codeedge-backend`

这是Maven项目的唯一标识，在同一个groupId下必须唯一，用来在Maven仓库里找到你的项目、打包发布、管理依赖。

作用

唯一标识你的Maven项目，和别人的项目区分开；
项目打包、发布到Maven仓库，全靠这个artifactId；
以后别人要引用你的项目，就是靠这个artifactId写依赖：

<dependency>
    <groupId>com.codeedgexu</groupId>
    <artifactId>codeedge-backend</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

小贴士

上线后如果修改了 artifactId，项目打包出来的jar包名字会变，别人引用你的项目也要同步改artifactId，不然就找不到依赖。

推荐用kebab-case短横线分隔的格式（比如codeedge-backend），可读性好，Maven全兼容，是行业里90%的项目都会用的写法。

`application.yml`文件中的`codeedge-backend`

1
2
3

spring:
  application:
    name: codeedge-backend

这是Spring Boot应用的官方服务名，核心作用是给微服务注册中心（Nacos）看的，是你这个服务在微服务集群里的唯一标识。

作用

Nacos服务注册的唯一标识

你的服务启动时，会去Nacos登记，登记的名字就是这个spring.application.name；

微服务之间调用的标识

以后有其他服务要调用你的接口，就是靠这个名字在Nacos里找到你的服务地址；

小贴士

同样地，上线后如果修改了这个服务名，Nacos里注册的服务名就变了，其他服务再用旧名字找你，就完全找不到了，微服务调用直接报错。

推荐和Maven的artifactId保持一致（比如也叫codeedge-backend），这样你在看Nacos控制台的时候，一眼就能对应上“这个服务对应Maven里的哪个项目”，不会混乱。

【面试真题拆解】十万用户并发下，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 无状态的痛点，给前端和后端之间搭了一座信任的桥梁，不用每次都输账号密码，不用服务器存储大量用户状态，还能完美适配现在的分布式项目。

【面试真题拆解】平时会收发短信吧？你知道短信里那种 `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. 数据统计和追踪

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

【面试真题拆解】你知道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 网际层的核心配套协议），仅从报文封装形式来看，它被直接封装在以太网帧中，因此也有观点认为它属于数据链路层。

【面试真题拆解】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。

【面试真题拆解】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。

MySQL的三层B+树能存多少数据？

Mon, 16 Mar 2026 13:09:19 +0000

InnoDB读写磁盘的最小单位是页（Page），默认大小16KB。
而MySQL的主键索引B+树，每一个树节点（不管是根节点、中间节点、叶子节点），本质上就是一个16KB的页。
所有计算，都是围绕【1个16KB的页，能存多少东西】展开的。

节点类型	存的内容	特点
非叶子节点（根节点、中间层节点）	只存主键值 + 指向下一层页的指针	不存完整用户数据，体积极小，一个页能存上千个
叶子节点（最底层节点）	存用户的完整一行行数据	存真实业务数据，体积大，一个页能存的行数有限

1.先算1个非叶子节点，能存多少个索引项

非叶子节点存的是「主键值 + 指针」，我们先算单个索引项的大小：

主键大小：假设主键是bigint类型，MySQL里bigint固定占8字节；
指针大小：InnoDB里指向页的指针，固定占6字节；
单个索引项总大小：8字节（主键） + 6字节（指针） = 14字节。

一个页是16KB，换算成字节是 16 × 1024 = 16384字节。
所以一个非叶子页能存的索引项数量：
16384 ÷ 14 ≈ 1170个

2.再算1个叶子节点，能存多少行数据

叶子节点存的是用户的完整一行行数据，假设一行业务数据占1KB（比如一张表有id、name、age、create_time等字段，加起来差不多1KB）。

一个页是16KB，所以一个叶子页能存的行数：
16KB ÷ 1KB/行 = 16行

3.最后算三层B+树的总数据量

顺着三层结构，从根节点往下算：

第一层（根节点）：1个非叶子页，能存1170个索引项 → 能指向1170个第二层的页；
第二层（中间非叶子节点）：1170个非叶子页，每个页又能存1170个索引项 → 能指向 1170 × 1170 = 1368900 个第三层的叶子页；
第三层（叶子节点）：每个叶子页能存16行数据。

最终总数据量 = 叶子页总数 × 每个叶子页的行数：
1170 × 1170 × 16 ≈ 2190万条

所以，三层B+树大约能存2000万条记录。

【面试真题拆解】Java类加载过程+双亲委派机制

Sun, 15 Mar 2026 22:44:04 +0000

什么是类加载？

简单来说，类加载就是把.class文件（编译后的字节码）从磁盘/网络加载到JVM内存里，并生成对应的Class对象的过程。

Java类加载的5个核心阶段

类加载不是一步到位的，而是分成了5个阶段： 加载➡️验证➡️准备➡️解析➡️初始化，其中加载、验证、准备、初始化的顺序是固定的，解析可能在初始化之后（为了支持动态绑定）。

1. 加载（Loading）

这是类加载的第一步，举个例子：假如你要加载User类，JVM会先找到User.class文件，把它的信息存到方法区，然后在堆里生成一个Class对象，以后你要访问User类的信息，都通过这个Class对象。

2. 验证（Verification）

这一步是为了保证JVM的安全，防止恶意或不规范的.class文件搞破坏，主要验证四个方面：

文件格式验证：检查.class文件的魔数（开头的CAFEBABE）、版本号（JDK版本兼容）等；
元数据验证：检查类的继承关系（比如不能继承final类）、方法重写是否合法等；
字节码验证：检查字节码指令是否安全（比如不会跳转到非法指令、不会访问越界的数组）；
符号引用验证：检查符号引用（比如类名、方法名）是否能找到对应的类/方法。

3. 准备（Preparation）

这一步是在方法区里为类的静态变量（static修饰的变量）分配内存，并设置初始默认值。

需要注意的是：不是代码里写的初始值，而是以下这些初始值：

数据类型	默认值
int	0
long	0L
float	0.0f
double	0.0d
boolean	false
引用类型	null

4. 解析（Resolution）

这一步是把常量池里的符号引用（比如类名com.example.User、方法名getUser），转换成直接引用（比如内存地址、指针）。

解析的话，主要针对的是类、接口、字段、方法等符号引用。

举个通俗一点的例子：

符号引用就是一个“代号”，比如你用“张三”指代一个人，不管他在哪，“张三”这个代号都能用；

而直接引用就是“具体的地址”，比如张三现在在“XX小区XX号楼XX室”，你可以直接找到他。

5. 初始化（Initialization）

这是类加载的最后一步，也是真正执行程序员写的代码的阶段。

这一步只做一件事：执行类构造器<clinit>()方法。

<clinit>()方法是编译器自动生成的，它会把类里的静态变量赋值语句和静态代码块（static {}）按顺序合并起来执行。

举个例子

public class User {
    static int num = 10; // 静态变量赋值
    static { // 静态代码块
        num = 20;
        System.out.println("静态代码块执行");
    }
}

以上代码在初始化阶段，JVM会执行<clinit>()方法：

先把num设为10，再设为20，然后打印“静态代码块执行”。

什么时候会触发类的初始化？

有以下6种情况：

创建类的实例（new User()）；
访问类的静态变量或静态方法（User.num、User.getUser()）；
用Class.forName("com.example.User")反射加载类；
初始化子类时，会先初始化父类；
JVM启动时，会先初始化包含main()方法的主类；
JDK 7+的动态语言支持，MethodHandle解析结果为REF_getStatic/REF_putStatic/REF_invokeStatic的句柄，且对应的类未初始化。

双亲委派机制（Parent Delegation Model）

什么是类加载器？

类加载器（ClassLoader）就是负责加载类的工具，JVM内置了三种类加载器：

启动类加载器（Bootstrap ClassLoader）

用C++写的，不是ClassLoader的子类，开发者无法直接获取它的引用。

负责加载JDK核心类库（比如java.lang.Object、java.lang.String），这些类在jre/lib/rt.jar里。

扩展类加载器（Extension ClassLoader）

是ClassLoader的子类，开发者可以获取它的引用，负责加载JDK扩展类库（比如jre/lib/ext目录下的类）。

应用程序类加载器（Application ClassLoader）

是ClassLoader的子类，也是默认的类加载器。负责加载用户自己写的类（比如com.example.User），也就是classpath下的类。

什么是双亲委派机制？

这里的“双亲”不是指“父母”，而是指“父类加载器”，是翻译的问题，理解成“父委派机制”更准确一点。

双亲委派机制的核心规则是：“向上委托，向下加载”

当一个类加载器收到加载类的请求时，它不会自己先加载，而是把请求委托给父类加载器去加载；
如果父类加载器能加载这个类，就由父类加载器加载；
如果父类加载器加载不了（比如在它的加载范围内找不到这个类），才会向下交给子类加载器自己加载。

举个例子

比如说：加载java.lang.Object

应用程序类加载器收到加载Object的请求，它不自己加载，委托给扩展类加载器；
扩展类加载器也不自己加载，委托给启动类加载器；
启动类加载器在rt.jar里找到了Object类，直接加载它；
加载完成，返回Class对象，不会再向下交给子类加载器。

为什么需要双亲委派机制？

双亲委派机制的目的是保证Java程序的安全性和稳定性，主要解决了两个问题：

避免类的重复加载

如果没有双亲委派，用户自己写一个java.lang.Object类，应用程序类加载器就会加载它，导致JVM里有两个Object类，程序就乱了。

保证核心类库的安全

防止用户恶意篡改核心类库（比如写一个恶意的java.lang.String类），因为核心类库只会由启动类加载器加载，用户写的同名类不会被加载。

破坏双亲委派机制的情况

常见的破坏双亲委派机制的场景：

JDBC的DriverManager

JDBC需要加载不同数据库的驱动（比如MySQL驱动），但驱动类是用户写的，启动类加载器加载不了，所以DriverManager用了线程上下文类加载器（Thread Context ClassLoader），打破了双亲委派，让启动类加载器能委托应用程序类加载器加载驱动。

Tomcat的类加载器

Tomcat需要隔离不同Web应用的类（比如两个应用都用了不同版本的Spring），所以它有自己的类加载器结构，每个Web应用有独立的类加载器，优先加载自己的类，而不是向上委托。

【面试真题】能讲讲MySQL的锁机制吗

Sun, 15 Mar 2026 16:44:46 +0000

MySQL的锁按两个维度分，刚好对应开发中最常遇到的问题：

按解决并发冲突的思路分，是悲观锁和乐观锁——这俩决定了“你是先占坑再干活，还是先干活最后再检查”；

按锁的范围大小分，是表锁、行锁，还有 InnoDB 特有的间隙锁 + 临键锁 —— 这三类锁决定了 “你是锁整个仓库（表锁）、只锁你要的那一件商品（行锁），还是锁仓库里的某个货架区间（间隙锁 + 临键锁）”。

先建一张最简单的电商商品表 product，插几条测试数据，等会更好理解举的例子：

CREATE TABLE `product` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `name` varchar(100) NOT NULL COMMENT '商品名称',
  `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存',
  `version` int(11) NOT NULL DEFAULT '0' COMMENT '乐观锁版本号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

-- 插入测试数据：id=1是iPhone，库存100；id=3是华为，库存200；id=5是小米，库存150
INSERT INTO `product` (`id`, `name`, `stock`, `version`) VALUES
(1, 'iPhone 17', 100, 0),
(3, 'Mate 70', 200, 0),
(5, 'Xiaomi 15', 150, 0);

悲观锁

举个电商秒杀扣库存的真实例子，也是悲观锁最典型的应用：

比如有两个用户同时秒杀iPhone 17，库存100。

如果不用锁，俩人同时查出来库存100，都扣减1，就超卖了。
用悲观锁的话，就是在查库存的时候用 SELECT ... FOR UPDATE 显式加排他锁——

第一个用户的事务先把这行数据锁住，第二个用户的查询就会阻塞，等第一个用户扣减完库存、提交事务释放锁，第二个用户才能拿到最新的库存，这样就保证了不超卖。

乐观锁

这也是开发中很常见的场景：两个运营同时修改同一件商品的标题。

这种场景并发冲突概率很低（因为很少会有两个人同时改同一个商品的标题），如果用悲观锁，每次修改都要加锁，太影响性能了，所以用乐观锁更合适。

乐观锁的意思就是：我假设没人跟我抢，所以我先直接修改，最后提交的时候再检查一下：

在我修改的这段时间里，有没有别人也改过这条数据？

如果没有，就修改成功；

如果有，就提示用户“数据已被修改，请刷新后重试”。

举个具体的SQL操作实例

我们打开两个命令行窗口，分表代表两个会话。

1.会话A（运营A先查商品）

1
2

-- 1. 运营A查出来iPhone的信息，此时 version = 0
SELECT * FROM product WHERE id = 1;

2.会话B（运营B同时查商品）

1
2

-- 1. 运营B也查出来iPhone的信息，此时 version 也是 0
SELECT * FROM product WHERE id = 1;

3.会话A（运营A先提交修改）

-- 1. 运营A把标题改成“iPhone 17 Pro Max”，WHERE条件带上 version = 0
UPDATE product 
SET name = 'iPhone 17 Pro Max', version = version + 1 
WHERE id = 1 AND version = 0;
-- 现象：返回更新行数为 1，修改成功！此时数据库里的 version 变成了 1

4.会话B（运营B后提交修改）

-- 1. 运营B把标题改成“iPhone 17 特价版”，WHERE条件也带上 version = 0
UPDATE product 
SET name = 'iPhone 17 特价版', version = version + 1 
WHERE id = 1 AND version = 0;
-- 现象：返回更新行数为 0，修改失败！
-- 因为数据库里的 version 已经变成 1 了，找不到 id=1 AND version=0 的行
-- 此时业务代码就可以提示用户：“商品已被其他运营修改，请刷新页面后重试”

表锁

直接锁整张表，其他会话对这张表的任何读写（不管是查哪一行、改哪一行）都会被阻塞。

举个例子

-- 会话A：给全表商品库存+10，显式加表锁
LOCK TABLES product WRITE;
UPDATE product SET stock = stock + 10;

-- 此时会话B想查id=1的商品，会直接阻塞！
SELECT * FROM product WHERE id = 1;

-- 会话A提交事务并释放表锁后，会话B才能执行
UNLOCK TABLES;

表锁的优点是加锁开销小、速度快，不会死锁，但缺点就是并发度极低，一锁全表，电商场景下用它会直接让网站卡死。

行锁

只锁具体的某一行数据，其他行完全不受影响，是InnoDB支持高并发的核心。

需要注意的是行锁的前提是【走索引】。

如果你的查询没走索引，InnoDB会退化成表锁。

举两个例子对比一下

先看走索引的情况（行锁生效）：

-- 会话A：用主键id=1查，加排他锁（走主键索引，只锁id=1这行）
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE;

-- 会话B：查id=3的商品，完全不阻塞！直接拿到锁
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 执行成功

-- 会话B：查id=1的商品，会阻塞！需要等会话A释放锁
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 阻塞

再看没走索引的情况（退化成表锁）：

-- 先确认name字段没加索引（前面建表的时候只给id加了主键）
-- 会话A：用name='iPhone 17'查，加排他锁（没走索引，锁全表！）
BEGIN;
SELECT * FROM product WHERE name = 'iPhone 17' FOR UPDATE;

-- 会话B：查id=3的商品，居然也阻塞了！因为锁了全表
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 阻塞

行锁的优点是并发度极高，只锁需要的行，不影响其他操作；但缺点是加锁开销大、速度慢，可能产生死锁。

间隙锁+临键锁

这俩是InnoDB特有的，专门用来解决【幻读】问题的。

先举个电商场景的例子说明一下什么是幻读？

-- 会话A：查id>1的所有商品（此时表里只有id=1、3、5）
BEGIN;
SELECT * FROM product WHERE id > 1 FOR UPDATE; -- 第一次查：查到id=3、5两条

-- 会话B：插了一条id=2的商品，提交事务
INSERT INTO product (id, name, stock, version) VALUES (2, 'OPPO Find X8', 100, 0);
COMMIT;

-- 会话A：再查id>1的商品，居然查到了id=2、3、5三条！
SELECT * FROM product WHERE id > 1 FOR UPDATE; -- 第二次查：多了一条，像产生了幻觉

这就是幻读：同一个事务里，两次相同的范围查询，结果却是不一样的。

间隙锁（Gap Lock）

间隙锁，间隙锁，顾名思义，它不锁具体的行，锁的是两个索引值之间的“间隙”，也就是只锁两个相邻索引值之间的空白区间，以防止别人在这个区间里插数据。

以刚开始建的那个product表为例：

id=1、3、5，间隙就是：(-∞,1)、(1,3)、(3,5)、(5,+∞)。

临键锁（Next-Key Lock）

临键锁其实是【行锁】+【间隙锁】的组合，锁的是左开右闭的区间。

比如(1,3]（锁id=3这一行，同时锁1到3之间的间隙）。

还是以刚开始建的那个product表为例，临键区间就是：(-∞,1]、(1,3]、(3,5]、(5,+∞)。

举个例子

-- 会话A：用id=3查，加排他锁（走主键索引，加临键锁(1,3]）
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE;

-- 会话B：想插id=2的商品，直接阻塞！因为间隙(1,3)被锁了
INSERT INTO product (id, name, stock, version) VALUES (2, 'OPPO Find X8', 100, 0); -- 阻塞

-- 会话B：想插id=6的商品，不阻塞！因为(5,+∞)没被锁
INSERT INTO product (id, name, stock, version) VALUES (6, 'Vivo X200', 100, 0); -- 执行成功

小贴士

间隙锁 + 临键锁只在 InnoDB 的默认隔离级别【可重复读（RR）】下生效。

如果是【读提交（RC）】隔离级别，会关闭间隙锁，只保留行锁。

夺命连环问：什么是死锁？又怎么避免呢？

两个或多个会话，互相持有对方需要的锁，都在等待对方释放，导致谁都执行不下去，形成“死循环”，这就是死锁。

举个例子

-- 会话A：先锁id=1，再想锁id=3
BEGIN;
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 持有id=1的锁
-- 此时会话A想拿id=3的锁，但被会话B持有了，阻塞
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 阻塞

-- 会话B：先锁id=3，再想锁id=1
BEGIN;
SELECT * FROM product WHERE id = 3 FOR UPDATE; -- 持有id=3的锁
-- 此时会话B想拿id=1的锁，但被会话A持有了，阻塞
SELECT * FROM product WHERE id = 1 FOR UPDATE; -- 阻塞

-- 结果：死锁！

死锁的四个必要条件

只要破坏其中任意一个，就能避免死锁：

互斥条件：一个锁只能被一个会话持有（行锁就是这样，没法破坏）；
请求与保持条件：持有一个锁的同时，又请求另一个锁；
不剥夺条件：锁只能由持有者主动释放，不能被别人强行抢走；
循环等待条件：会话之间形成循环等待链（A等B，B等A）。

怎么避免死锁？

① 按固定顺序加锁

所有会话都按相同的顺序加锁，比如都先锁id小的，再锁id大的，这样就不会形成循环等待。

② 减少锁的范围和持有时间

尽量用行锁不用表锁；

事务尽量小，不要在事务里做无关操作（比如不要在事务里调第三方接口、查无关表），锁持有时间越短，死锁概率越低。

③ 避免大事务

大事务持有锁的时间长，涉及的行多，更容易死锁，把大事务拆成多个小事务。

小贴士

InnoDB 有自动死锁检测机制，它会实时扫描锁等待链，一旦发现死锁，会自动回滚其中一个，一般是代价较小的那个事务，比如更新行数少的那个，让另一个事务继续执行，不会让系统无限期卡死。

TCP的核心参数-MTU、MSS、RTT、RTO、cwnd、ssthresh

Sun, 15 Mar 2026 11:36:23 +0000

MTU和MSS，管【单个TCP包到底发多大最合适】，是整个传输的基础；

RTT和RTO，管【包发出去之后，怎么保证对方一定收到，丢包了怎么办】，是TCP可靠传输的核心；

cwnd和ssthresh，管【一次能连续发多少个包，怎么既跑满带宽，又不把网络堵死】，是TCP拥塞控制的核心。

MTU & MSS

MTU（最大传输单元，Maximum Transmission Unit）

平时用的以太网、WiFi，硬件层面就规定了一个完整的IP数据包，最大不能超过1500字节，这个上限就是MTU。
如果IP包超过MTU，就会被拆成好几个小分片传输，只要有一个分片丢了，整个包就得全量重传，特别影响效率，还可能被防火墙拦截。

MSS（最大报文段长度，Maximum Segment Size）

这是基于MTU算出来的、TCP包里真正能装的业务数据的最大长度——要把IP头、TCP头的空间提前扣掉。
以太网默认MTU1500字节，标准IP头和TCP头各占20字节，所以默认MSS就是1460字节。

它是TCP三次握手的时候，客户端和服务端协商出来的，最终取两边的最小值，目的就是从源头避免IP拆包。

RTT & RTO

RTT（往返时延，Round-Trip Time）

我发一个TCP包出去，到我收到对方回的【我收到了】的ACK确认包，这一来一回花的时间，就是RTT。
它是网络环境决定的客观值，网络越拥堵、跨的路由越多，RTT就越长，会实时波动，是算RTO的唯一基础。

RTO（重传超时时间，Retransmission TimeOut）

我发出去一个包，会设一个定时器，要是超过这个时间还没收到ACK，我就认为这个包丢了，马上重发一个，这个定时器的时间就是RTO。
RTO完全是基于RTT算出来的，不是固定死的。

它必须比RTT大一点。

如果太小了，ACK还在路上就瞎重传，浪费带宽；

但太大了，真丢包了半天不重传，传输变慢。

所以，网络波动RTT变了，RTO也会跟着实时调整。

cwnd & ssthresh

这两个参数是TCP拥塞控制的核心，TCP刚建连的时候，根本不知道当前网络能扛住多大流量，发少了浪费带宽，发多了直接把网络堵死，所以用这两个参数控制发送节奏。

cwnd（拥塞窗口，Congestion Window）

TCP发送端自己维护的【油门】，单位是MSS。这个参数决定了在没收到对方ACK之前，我最多能连续发多少个包。

比如cwnd=10，就是最多连续发10个MSS大小的包，不用等ACK。
需注意的是，cwnd不是固定的，网络越好、丢包越少，cwnd就越大，发送速度就越快；一旦丢包，就会马上降下来。

ssthresh（慢启动阈值，Slow Start Threshold）

cwnd的【换挡开关】，用来划分两个发送阶段，单位也是MSS。
当cwnd ＜ ssthresh时，进入慢启动阶段，cwnd每过一个RTT就直接翻倍，指数级快速涨速，尽快把带宽跑满；

当cwnd ≥ ssthresh时，进入拥塞避免阶段，cwnd每过一个RTT才加1，线性慢慢涨，避免冲太猛把网络堵死。
一旦检测到网络拥堵丢包，ssthresh会立刻降到当前cwnd的一半，再根据丢包的严重程度调整cwnd，重新控制发送节奏。

【面试真题】讲讲JVM的垃圾回收机制？

Sat, 14 Mar 2026 19:26:46 +0000

为什么需要垃圾回收？

首先得说清楚，JVM的垃圾回收（GC）到底是干嘛的。

其实就像租房子住，时间长了会产生垃圾，要是不打扫，房子就没法住了。

在Java里，我们写代码会创建很多对象（比如new Person()、new ArrayList()），这些对象都存在堆内存里。

但是，堆内存是有限的，要是对象用完了不清理，内存就会被占满，最后报OutOfMemoryError（OOM），程序就挂了。

所以GC的作用就是：自动找到堆里那些“没人用的垃圾对象”，把它们清理掉，腾出内存空间。

堆内存划分

JVM把堆分成了新生代和老年代两大块：

新生代：刚创建的对象优先放在这里。就像“幼儿园”，大部分对象“朝生夕死”（比如方法里的临时变量，方法执行完就没用了）。
老年代：在新生代里“熬过好几次GC”的对象，会被放到这里。就像“养老院”，这里的对象大多活得比较久（比如Spring容器里的单例Bean）。

那为什么要这么划分呢？

主要还是因为不同生命周期的对象，用不同的回收算法，效率会更高一点。

各代用什么垃圾回收算法？

我当时面试的时候突然懵了，说的不知道，裂开。。。

对新生代来说，它的特点是：垃圾多，存活对象少（比如100个对象里，可能只有2个活着）。

采用的是复制算法。

JVM把新生代分成三块：

1个Eden区（占80%）和2个Survivor区（From和To，各占10%）。

平时只用Eden区和其中一个Survivor区（比如From）。

新对象先在Eden区分配，当Eden区满了，触发Minor GC（新生代GC），把Eden和From区里活着的对象，复制到To区，然后直接清空Eden和From区，From和To交换角色（下次用Eden和新的From区）。

对老年代来说，它的特点是：存活对象多，垃圾少，而且没有额外的大空间做复制担保，所以不用复制算法，采用的是**标记-清除 **或 标记-整理算法。

标记-清除算法（Mark-Sweep）

这种算法的实现逻辑是，从“GC Roots”（比如主线程、静态变量这些“根”）出发，找到所有活着的对象，做上标记，然后遍历堆内存，把没标记的对象（垃圾）清理掉。

优点是实现简单，但是会产生内存碎片（比如清理后剩下很多小空间，大对象可能放不下）。

标记-整理算法（Mark-Compact）

为了解决内存碎片问题，在“标记-清除”基础上加了个“整理”步骤。

实现逻辑和标记清除算法一样，先标记存活对象，把所有存活对象往内存的一端移动，按顺序排好，最后，直接清空边界以外的内存。

这种算法的优点是没有内存碎片，但缺点是需要移动对象，效率比“标记-清除”低。

常见的垃圾回收器

Serial：单线程回收，适合客户端应用（比如桌面软件）；
ParNew：Serial的多线程版，常和CMS配合用；
CMS（Concurrent Mark Sweep）：主打低延迟（垃圾回收时尽量不让程序停顿太久），适合互联网应用（比如电商后台），用的是“标记-清除”算法；
G1（Garbage-First）：把堆分成很多小区域，优先回收垃圾多的区域，平衡了吞吐量和延迟。

【面试真题】Java中什么是反射

Sat, 14 Mar 2026 12:16:58 +0000

首先，官方的定义是这样的：

Java反射（Reflection）是指在程序运行时，动态获取类的完整结构信息（如构造方法、字段、方法），并能直接操作对象的属性或方法的机制。

正射 vs 反射

用【创建对象并调用方法】举个例子：

正射

就是我们平时写代码的方式，编译期就知道要操作的类是什么，直接 new 对象调用方法：

1
2
3

// 正射：编译期就确定是User类
User user = new User();
user.setName("张三"); // 直接调用方法

反射

动态的方式**，编译期**不知道要操作的类是什么，运行期才通过类名字符串动态获取类信息并操作：

// 反射：运行期才通过字符串"com.example.User"获取类
Class<?> clazz = Class.forName("com.example.User");
Object user = clazz.getDeclaredConstructor().newInstance(); // 动态创建对象
Method setNameMethod = clazz.getDeclaredMethod("setName", String.class);
setNameMethod.invoke(user, "张三"); // 动态调用方法

原理

反射的底层，其实是操作JVM加载类后生成的 Class对象。

先回顾一下类的加载过程：

编译期：.java文件被编译成 .class字节码文件；
类加载期：JVM的类加载器（ClassLoader）把 .class文件加载到内存，生成一个 java.lang.Class对象（这个对象包含了类的所有结构信息）；
运行期：反射就是通过这个 Class对象，逆向获取类的构造方法、字段、方法等信息，并进行操作。

说人话就是：Class对象是反射的入口，所有反射操作都从获取Class对象开始。

手撕一下，加深理解

1. 获取Class对象的3种方式

// 方式1：类名.class（最常用，编译期就能获取）
Class<User> clazz1 = User.class;

// 方式2：对象.getClass()（已有对象时用）
User user = new User();
Class<? extends User> clazz2 = user.getClass();

// 方式3：Class.forName("全类名")（最灵活，框架常用）
Class<?> clazz3 = Class.forName("com.example.User");

2. 操作构造方法：动态创建对象

Class<?> clazz = Class.forName("com.example.User");

// 获取无参构造方法并创建对象
Constructor<?> noArgConstructor = clazz.getDeclaredConstructor();
Object user1 = noArgConstructor.newInstance();

// 获取有参构造方法并创建对象
Constructor<?> argConstructor = clazz.getDeclaredConstructor(String.class, int.class);
Object user2 = argConstructor.newInstance("张三", 25);

3. 操作字段：动态获取/设置属性

Class<?> clazz = Class.forName("com.example.User");
Object user = clazz.getDeclaredConstructor().newInstance();

// 获取public字段并赋值
Field nameField = clazz.getField("name");
nameField.set(user, "张三");

// 获取private字段并赋值（需打破封装）
Field ageField = clazz.getDeclaredField("age");
ageField.setAccessible(true); // 关键：打破private访问限制
ageField.set(user, 25);

4. 操作方法：动态调用方法

Class<?> clazz = Class.forName("com.example.User");
Object user = clazz.getDeclaredConstructor().newInstance();

// 获取public方法并调用
Method setNameMethod = clazz.getMethod("setName", String.class);
setNameMethod.invoke(user, "张三");

// 获取private方法并调用（需打破封装）
Method getAgeMethod = clazz.getDeclaredMethod("getAge");
getAgeMethod.setAccessible(true);
int age = (int) getAgeMethod.invoke(user);

实际应用场景

Java生态里的核心框架几乎都用到了反射，比如：

1. Spring框架的IOC/DI

Spring的IOC容器就是通过反射创建对象并注入依赖的：

在XML里写 <bean id="user" class="com.example.User"/>➡️Spring读取XML，拿到全类名 com.example.User➡️Spring通过 Class.forName() 获取Class对象，动态创建Bean对象➡️如果Bean有依赖（比如 userService 依赖 userDao），Spring再通过反射注入依赖。

2. JDBC加载数据库驱动

Class.forName("com.mysql.cj.jdbc.Driver")，底层就是反射：首先加载驱动类到JVM，接下来驱动类的静态代码块会自动执行，把驱动注册到 DriverManager 里。

3. 注解处理

比如JUnit的 @Test 注解：JUnit启动后，通过反射扫描所有类，找到带 @Test 注解的方法，再通过反射动态调用这些方法执行测试。

反射的优缺点

优点

灵活性高：运行期才确定要操作的类，不需要在编译期写死；
动态性强：适合开发通用框架（如Spring、MyBatis），框架不需要知道用户会写什么类，通过反射就能动态适配。

缺点

性能低：反射比直接调用方法慢10-100倍（因为需要动态解析类信息），所以高频调用的场景（比如循环里）尽量不用反射；
破坏封装性：可以通过 setAccessible(true) 访问private字段/方法，破坏了Java的封装原则；
安全性问题：反射可以执行任意代码，可能被恶意利用。

【面试真题】缓存和数据库的一致性问题如何保证？

Fri, 13 Mar 2026 14:14:10 +0000

坦白说，这个问题本质上不是个纯技术方案题，而是高并发场景下，平衡【性能、可用性、一致性强度】的工程题。

核心是先看业务的一致性容忍度，再选对应方案，而且必须做好异常兜底，不然线上一定会出永久脏数据。

在电商场景中，绝大多数情况下优先保证最终一致性，只有金融级核心链路才会考虑强一致性。

先说标准流程：

读请求：先查缓存，命中直接返回；没命中就读数据库，把结果写回缓存再返回。
写请求：先更新数据库，再删除缓存。

为什么是【删除缓存】，而不是【更新缓存】？

一是并发写场景下，更新缓存一定会有数据覆盖的风险；

二是电商场景很多缓存值是多表关联算出来的，更新缓存的成本极高，不如删除后懒加载；

三是写多读少的场景，频繁更新缓存全是无效操作，浪费性能。

为什么是【先更库，再删缓存】，不能反过来？

如果你刚把缓存删了，数据库还没更新完，这时候高并发的读请求进来，缓存查不到，直接去数据库拉了旧数据，还写回了缓存。

等你数据库更新完，缓存里的旧数据就一直躺在那，除非缓存过期，不然用户一直看到的是错的数据。

但是，如果是先更库再删缓存，只有极小概率会出问题，比如：

读请求缓存没命中，正在读数据库的瞬间，写请求更新了数据库并删了缓存，之后读请求把旧数据写回缓存。

但是，但是啊，这个场景发生的条件太苛刻了，因为写数据库的耗时远大于读数据库，基本卡不中这个时间窗口，线上出问题的概率几乎可以忽略。

就算真的撞上了，还有缓存 TTL 兜底，最多就是短时间不一致，绝对不会出永久脏数据。

其实，这个方案最大的风险，是第二步删缓存失败。

同步删缓存如果失败，立刻把这个key丢到消息队列里做异步指数退避重试，设置最大重试次数，绝对不让缓存操作阻塞主流程。

高并发下的两个进阶方案

第一个是延迟双删，解决基础方案的极端并发问题。
“针对商品详情、营销活动这种超高并发读的场景，用延迟双删做加固，流程是：

先删除缓存➡️更新数据库➡️延迟500ms-1s，二次删除缓存。
第二次延迟删除，刚好能覆盖掉【数据库更新过程中，读请求写回缓存的旧数据】，彻底解决极端并发的脏数据问题。
其中，延迟时间必须大于【业务读请求的最大耗时 + 数据库主从同步延迟】。

第二个是基于Binlog的异步缓存淘汰。
用Binlog异步淘汰缓存，完全解耦业务和缓存操作。

业务代码只做一件事：更新数据库，完全不碰缓存。

然后用Canal监听数据库的binlog增量日志，只有主库事务提交成功，才会拿到数据变更事件，再异步去删除对应的缓存key。如果删除失败，就丢进死信队列重试，超过阈值直接触发告警。

强一致性方案

只有像支付账户余额、核心库存扣减这种，一分钱都不能错、零容错的场景，才会考虑强一致性方案，因为它的性能代价极大。
用Redisson的分布式读写锁，写请求加写锁，读请求加读锁，读写互斥，强制串行化，彻底避免并发问题。

但这个方案会严重降低系统吞吐量，高并发下很容易出现锁等待、超时问题，所以非核心场景，绝对不会用。

兜底机制

不管方案设计得多完美，线上一定会有意外，比如：

缓存集群炸了、消息队列挂了、binlog消费延迟了，没有兜底，就等着出线上事故。
可以采用以下兜底策略：

TTL兜底：所有缓存key必须设置合理的过期时间，哪怕所有机制都失效了，最多就是一段时间的不一致，缓存一过期，就自动拉取最新数据，绝对不会出现永久脏数据。
失败重试机制：所有缓存删除操作，必须有异步重试兜底，不能一次失败就放任脏数据存在。
降级开关：大促场景下，如果缓存集群扛不住了，直接开降级开关，所有请求切到读数据库，先保证用户能下单，别的都好说。

IDEA运行SpringBoot测试报错“命令行过长”？

Wed, 11 Feb 2026 12:44:33 +0000

在项目中想通过引入Redisson实现限流，运行RedisLimiterManagerTest.doRateLimit测试方法时，弹出了这样的提示：

原因分析

当项目依赖较多时，IDEA运行测试需要加载的类路径（各种依赖包的路径）会变得很长，而Windows对命令行参数的长度有默认限制（通常是8191字符），超出后就会触发“命令行过长”的错误。

解决方法

1.点击IDEA右上角的运行配置下拉框 ➡️选择【编辑配置】，打开运行/调试配置窗口：

2.在配置窗口右侧，找到并点击【修改选项(M) Alt+M】按钮，弹出选项菜单后，选择【缩短命令行】，此时界面会出现【缩短命令行】的下拉框，直接选择【JAR 清单】，这样的话IDEA会通过生成临时JAR清单来管理类路径。

3.最后点击窗口右下角的【应用】➡️再点击【确定】，保存配置。

4.重新运行RedisLimiterManagerTest.doRateLimit测试方法，能正常执行并输出“成功”日志，命令行过长的问题解决~

怎么知道本地的Redis有没有设置密码

Wed, 11 Feb 2026 11:50:41 +0000

进入到Redis的安装目录：

双击【redis-server.exe】,如果双击之后窗口一闪而过，检查一下默认的6379端口是否被占用：

1
2

# 查看 6379 端口是否被占用
netstat -ano | findstr 6379

如果输出类似下面这样的信息：

1
2
3

# 类似这样的输出:
TCP    127.0.0.1:6379    0.0.0.0:0    LISTENING    12345
                                                      ↑这是进程ID

说明 6379 端口已被进程占用，再检查是否已有 Redis 服务在运行：

1
2

# 查看 Redis 服务状态
sc query Redis

如果输出：

1
2
3

SERVICE_NAME: Redis
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING

说明Redis 已经作为 Windows 服务在后台运行了，导致了端口被占用。

接下来，直接使用已经运行的 Redis，直接双击安装目录下的【redis-cli.exe】，在弹出的窗口输入【config get requirepass】,如果以下的（2）为空，表示没有设置密码。

Redis、内存、缓存、MySQL、数据库，这些的区别到底是什么

Sun, 01 Feb 2026 13:02:50 +0000

这几个词经常一起出现，有次面试的时候被问到了，还是有点懵的，本文就来理清一下。

1. 内存（Memory）

本质上是硬件，比如电脑/服务器上的内存条，速度极快（纳秒级），缺点是断电会导致数据丢失。

需要注意：程序运行时必须把数据加载到内存才能执行。

2. 数据库（Database）

本质上是软件，用来持久化存储数据（断电不丢失），提供查询、修改、事务等能力，数据存在硬盘。

3. MySQL

本质上是关系型数据库（ Relational Database Management System, RDBMS），数据存在硬盘，支持 SQL、事务、索引、复杂查询，速度比内存慢很多（毫秒级）。

需要注意的是MySQL 是数据库的一种，但是数据库 ≠ MySQL。

4. 缓存（Cache）

本质上其实是一种“加速思想或者机制”，不是软件也不是硬件，而是一种设计模式，主要用于把热点数据放在更快的地方，减少查询压力。

5. Redis

本质上是基于内存的 NoSQL 数据库，数据主要存在内存，也可以持久化到硬盘，常被当作分布式缓存使用。

需要注意的是：

Redis 是一个数据库，Redis ≠ 缓存，只是它常被用来做缓存，但它功能远不止缓存，比如也可以做排行榜、限流、分布式锁等等。

Spring Boot的多环境配置

Mon, 26 Jan 2026 15:27:48 +0000

在开发Spring Boot项目中，如果我们想把自己的项目开源到Github仓库，application.yml中的某些配置比如MySQL、Redis的账户密码，还有的就是现在引入AI之后的一些密钥，可能都不太愿意推送到仓库去。

这个时候，可以通过配置多环境来解决，给本地一个专有的配置文件，然后将其添加到.gitignore文件中，这样就有效解决了这个问题。

下面介绍一下 Spring Boot的多环境配置方法：

Spring Boot 支持的多环境配置文件，命名规则为 application-{profile}.yml（profile 是环境标识，如local/dev/test/prod）。

操作步骤

application.yml（公共配置）

spring:
  application:
    name: xxx
  profiles:
    active: local  # 激活local环境

# springdoc-openapi（所有环境都用这个扫描包，通用）
springdoc:
  group-configs:
    - group: 'default'
      packages-to-scan: com.xx.xx.controller

# knife4j（所有环境都开启，中文界面，通用）
knife4j:
  enable: true
  setting:
    language: zh_cn

application-local.yml（本地开发专属配置）

# 本地专属：端口、上下文路径
server:
  port: xxxx
  servlet:
    context-path: /api

# 本地专属的其他配置（比如数据库、日志、Redis等）
# spring:
#   datasource:
#     url: jdbc:mysql://localhost:3306/xx?useSSL=false&serverTimezone=UTC
#     username: xx
#     password: xx
#     driver-class-name: com.mysql.cj.jdbc.Driver
# logging:
#   level:
#     com.xx.xx: debug  # 本地开发开启debug日志
# redis:
#   host: localhost
#   port: xxxx

通过在 application.yml 中配置 spring.profiles.active 激活指定环境，最后的加载顺序就是：

先加载公共配置 application.yml；
再加载激活的环境配置 application-local.yml；

这样的话，环境配置中的同名配置项会覆盖公共配置，不同配置项自动合并，实现 “公共 + 专属” 并存。

JDK版本的区别

Mon, 26 Jan 2026 15:05:04 +0000

在IDEA中新建Spring Boot项目时，需要选择JDK版本，这里小记一下：

Oracle OpenJDK

Oracle 官方维护的开源免费JDK，Java标准实现。

Amazon Corretto

亚马逊基于 OpenJDK 定制的免费、长期支持JDK。

JetBrains Runtime

JetBrains（IDEA/PyCharm 等 IDE 厂商）专为 IDE 自身运行定制的 JDK。

【字节面试手撕】大数加法

Sun, 25 Jan 2026 22:48:06 +0000

求解代码

public String solve(String s, String t) {
    // 如果第一个字符串为空/长度为0，直接返回第二个字符串
    if(s.length()<=0){
        return t;
    }
    // 如果第二个字符串为空/长度为0，直接返回第一个字符串
    if(t.length()<=0){
        return s;
    }

    int i = s.length()-1;

    int j = t.length()-1;
    // 定义进位变量tmp
    int tmp = 0;
    // 定义StringBuilder拼接结果
    StringBuilder sb = new StringBuilder();

    // 需要注意：最后一位相加仍有进位时，需把进位1也拼接到结果
    while (i>=0||j>=0||tmp!=0) {

        tmp += i>=0?s.charAt(i--)-'0':0;

        tmp += j>=0?t.charAt(j--)-'0':0;
        
        // 取余10：得到当前位的计算结果
        sb.append(tmp%10);
        // 除以10：更新进位值
        tmp=tmp/10;
    }
    // 结果逆序：因为是从个位开始拼接，需要反转回正序，再转字符串返回
    return sb.reverse().toString();
}

MySQL中有哪些日志类型？

Sat, 24 Jan 2026 15:38:05 +0000

MySQL有binlog、redo log和undo log三种日志，其中binlog 负责主从复制和数据恢复，redo log保证崩溃后数据不丢失，undo log支撑事务回滚和MVCC。

1.binlog

binlog 是server层的日志，记录的是逻辑操作，也就是原始SQL或者行变更前后的值。

它的核心场景是主从同步，从库拉取主库到binlog重放一遍就能保持数据一致。

另外，做数据恢复的时候，也是靠binlog配合全量备份回放到指定时间点。

2.redo log是InnoDB引擎独有的，记录的是物理变更，具体就是“某个数据页的某个偏移量改成了什么值”。

它的作用是崩溃恢复（crash-safe），基于WAL（Write Ahead Log）机制，MySQL挂了重启后，InnoDB会用redo log把没来得及刷盘的脏页恢复出来。

redo log是循环写的，空间固定，写满了就得等checkpoint推进才能继续。

3.undo log也是InnoDB引擎的逻辑日志，记录的是数据修改前的旧值。

事务回滚的时候，就靠undo log把数据改回去，另外MVCC的快照读也依赖它，别的事务要读历史版本，顺着undo log链往前找就行。

MySQL是怎么实现事务的？

Fri, 23 Jan 2026 15:59:01 +0000

MySQL实现事务靠的是4个核心组件：

Redo Log
Undo Log
锁
MVCC

这四个组件分别对应事务的ACID特性的不同方面，一致性是由原子性、隔离性、持久性共同作用实现的。

1.Redo Log保证持久性（D）

在事务提交时，基于WAL（预写日志）机制将修改先写到Redo Log再刷盘写磁盘数据页。

就算写数据页时宕机了，重启后通过重放redo log就能恢复数据，确保已提交的修改不会丢失。

2.Undo Log保证原子性（A）

每次修改数据前，先把原值以逻辑日志的形式存到undo log中。

事务回滚时，按undo log反向操作把数据恢复回去。

要么全做完，要么全撤销，不会出现改了一半的中间状态。

3.锁机制保证隔离性（I）的写-写并发

两个事务同时改同一行，必须一个等另一个释放锁，实现写-写互斥。

InnoDB的锁粒度精确到行级（基于索引实现），还有间隙锁防止幻读。

4.MVCC保证隔离性（I）的读-写并发

读操作不加锁，通过undo log构建的版本链找到自己应该看到的数据版本，主要适配InnoDB默认的可重复读隔离级别RR。

写的时候别人照样能读，读的时候别人照样能写，大幅度提升读写并发度。

一致性不是单独实现的，它是原子性、隔离性和持久性共同作用的结果。

数据从一个正确状态转移到另一个正确状态，中间不会出现不一致的中间态，同时满足业务的约束规则。

解释一下为什么要有虚拟内存

Thu, 22 Jan 2026 19:18:56 +0000

虚拟内存的核心作用：

● 扩展程序地址空间

● 隔离进程地址空间

● 简化内存管理

虚拟内存允许程序运行在比实际物理内存更大的地址空间上。即使物理内存不足，系统也可以将不常用的页面移到磁盘的交换区，释放内存给活跃的程序使用，避免程序因内存不足而终止。
操作系统通过页面表为每个内存页面设置访问权限，并由MMU在地址转换时校验权限。如果程序尝试非法访问，OS会拦截并触发异常，防止破坏其他程序或系统内核。
虚拟内存将程序的逻辑地址与物理地址分离，一方面可以让程序员无需关心物理内存布局，简化开发；另一方面可以让进程拥有独立的虚拟地址空间，进程间无法直接访问，实现地址隔离，避免相互干扰。

MyBatis Flex和MyBatis Plus的区别

Thu, 22 Jan 2026 15:00:00 +0000

MyBatis Flex和MyBatis Plus都是对原生MyBatis 框架的增强工具，都能够简化数据库的操作、提高开发效率。

两者在设计理念和功能侧重点上有以下区别：

1.MyBatis Flex除了MyBatis自身，没有任何第三方依赖，极致轻量化；而MyBatis Plus整合的功能更多（如逻辑删除、乐观锁、代码生成等），依赖也更复杂。

2.MyBatis Flex从架构上进行了优化，在SQL执行的过程中没有SQL解析环节和MyBatis拦截器，通过 AST抽象语法树构建SQL，执行链路更短，可以带来更高的性能。而MyBatis Plus大量依赖MyBatis拦截器解析SQL，执行链路更长，有一定解析开销。

3.MyBatis Flex原生支持多表关联查询，无需手写SQL，适合处理复杂的业务场景；而MyBatis Plus在多表查询时需要依赖第三方插件或者手写SQL来实现。

如何在MySQL中监控和优化慢SQL？

Tue, 20 Jan 2026 18:04:18 +0000

在MySQL中监控和优化慢SQL的核心是开启MySQL的慢查询日志，慢查询日志会把执行时间超过设定阈值的SQL语句自动记录下来，通过日志的分析与执行计划的校验实现SQL性能的精准优化。

主要步骤：

1.开启慢查询日志，设置合理的时间阈值，线上环境通常将阈值设定为1~2秒，确保执行耗时较长的慢SQL能够被精准捕获。

2.定期对慢查询日志进行分析，用MySQL自带的分析工具mysqldumpslow或Percona Toolkit里的pt-query-digest工具，对日志中的SQL进行汇总统计，定位高频出现的慢SQL。

3.对高频的慢SQL执行EXPLAIN命令分析其执行计划，检查是否走索引、扫描数据行数、是否存在文件排序等问题，再针对分析结果开展针对性优化。

几个常见的慢SQL优化方向

1.查看EXPLAIN 结果的type字段，如果值为ALL，说明当前SQL是全表扫描；如果key列为空，就说明该SQL未使用索引，需优化索引配置。

2.如果SELECT查询的字段没有包含在索引里，会触发回表查询，可以通过构建覆盖索引进行优化，把查询所需的字段都放进索引。

3.查看EXPLAIN结果的Extra字段，如果是Using filesort，说明数据库执行了手动排序；如果是Using temporary，说明用了临时表；这两种情况都可以通过为对应字段添加索引来避免。

4.避免用SELECT *查询所有字段，可以明确指定所需的字段；可以通过添加LIMIT子句控制单次查询返回的条数，从而减少数据处理压力。

什么是RPC框架

Mon, 19 Jan 2026 17:43:23 +0000

RPC（Remote Procdure Call）远程过程调用是一种用于实现在分布式系统中进行跨网络通信的技术，也是一种计算机通信协议。

RPC框架是基于RPC协议实现的。

RPC允许一个程序（服务消费者）像调用自己程序的方法一样，调用另一个程序（服务提供者）的接口，无需关心数据的传输处理、数据编解码和底层网络通信的细节。

这样一种功能的实现都是由RPC框架来完成的，这就使得开发者能够更轻松地调用远程服务，快速开发分布式系统。

RPC框架通常采用的是高效地网络通信协议（主流为性能远超HTTP的TCP协议）和高效轻量的序列化/反序列化机制；

RPC框架提供的负载均衡、服务发现和容错机制（超时重试、熔断降级、限流等）可以提高系统的可靠性、可用性以及稳定性。

除此之外，开发者还可以自定义负载均衡器和序列化协议，动态地扩展RPC的功能。

MySQL中如何进行SQL调优

Mon, 19 Jan 2026 17:23:03 +0000

SQL调优的核心思路是减少磁盘I/O和避免无效计算。

主要就是先通过MySQL的慢查询日志定位慢SQL，再利用EXPLAIN分析执行计划，最后再进行针对性优化。

优化的手段主要有这几大类，分别是索引层面的优化，SQL写法层面的优化以及架构层面的优化。

索引层面的优化

合理设计联合索引，利用覆盖索引来避免回表。
注意最左匹配原则。
避免在索引列上做函数运算、隐式类型转换。
及时删除荣誉索引和重复索引。

SQL写法层面的优化

为了减少网络传输和内存占用，只对必要字段进行查询，不使用select *
为了避免全表扫描，避免%LIKE这种前缀模糊查询
连表查询时检查关联字段的字符集和排序规则是否一致，不一致会导致索引失效

架构层面的优化

对于访问频率高但是变化少的数据使用Redis缓存
对单表数据量超过2000万行或物理文件超过2G的大表进行分库分表
搭建主从数据库集群，进行读写分离，让从库分担一些查询的压力

什么是Spring-Bean

Mon, 19 Jan 2026 15:50:02 +0000

任何通过Spring 容器实例化、组装和管理的Java对象都能称之为Spring Bean。

Bean可以看成是Spring应用中的一个普通Java对象，这个对象的创建、属性赋值、初始化、销毁等完整的生命周期是由Spring IOC容器来统一管理的，并非程序员手动控制。

Spring Bean的生命周期分为实例化、依赖注入、初始化以及销毁这4个固定不可逆的阶段。

当Spring 容器启动时，会根据配置文件或者注解，先实例化Bean；

之后，Spring 容器再通过注解（@Autowired）或者setter方法将Bean的依赖属性注入进来；

依赖注入完成后，如果Bean标注了@PostConstruct注解、实现了InitializingBean接口或者配置了init-method，Spring就会调用相应的初始化方法，完成Bean的初始化操作。

初始化完成后，Bean就进入到了就绪状态，可以被程序获取和使用了。

如果Bean标注了@PreDestroy注解、实现了DisposableBean接口或者配置了destroy-method，Spring会在容器关闭时调用对应的销毁方法，完成Bean的资源释放。

什么是Spring-IOC

Sun, 18 Jan 2026 18:12:06 +0000

Spring IOC（Inversion of Control）控制反转是将对象的创建权和对象之间依赖关系的维护权，从程序员的业务代码中转移到由Spring IOC容器中，程序员就不再手动控制了。

需要说明的是，Spring IOC是一种设计思想，不是一个具体的技术，Spring IOC 的具体落地实现是通过依赖注入（Dependency Injection）完成的。

依赖注入的方法有构造器注入、setter注入和接口注入三种。

那控制反转它控制的是什么呢？

其实就是控制的是对象的创建过程，Spring IOC容器会根据配置文件来创建对象。

那反转的是什么呢？

反转的是创建对象并且为这个要创建的对象注入它所依赖的对象这个动作的主动权。

传统开发过程是由程序员主动new一个对象，手动注入依赖，Spring IOC是将这个动作交给容器来自动完成，这样主动权就发生了反转。

举个🌰说明一下：

比如对象A依赖对象B，那在创建对象A的代码里，我们就需要写好应该如何创建对象B，只有这样才能创建一个完整的对象A。

但是，反转之后，这个动作就会由Spring IOC容器去触发，容器在创建对象A的时候，发现对象A它依赖对象B，根据配置文件，容器就会创建对象B，然后将对象B注入到对象A中。

这里要注意一下，例子中的是注入一个对象，其实还可以注入配置文件中的一个值、集合等等。

说说Java中的反射机制

Sun, 18 Jan 2026 17:36:55 +0000

反射机制是让程序在运行的时候能够动态地获取类的方法、字段、构造函数这些结构信息，还能对其直接进行操作，这样，程序在编译时不需要知道具体的类型，等到运行时再决定要调用哪个类和方法。

反射机制主要有3大核心流程：

获取Class对象➡️获取成员信息➡️操作目标对象。

获取Class对象的方式：

1.全限定类名获取

`1`	`Class<?> cla = Class.forName("xxx.xxx.MyClass");`

2.字面量获取

`1`	`Class<?> cla = MyClass.class;`

3.对象实例获取

`1`	`Class<?> cla = obj.getClass();`

获取成员信息

主要是从Class对象中获取字段Field、方法Method以及构造函数Constructor

操作目标对象

主要是创建实例、读写字段和调用方法。

Java中HashMap的默认负载因子为什么设置为0.75

Sun, 18 Jan 2026 17:11:19 +0000

0.75这个数字其实是一个时间和空间之间的平衡点。

负载因子决定了什么时候会触发扩容。

HashMap的扩容阈值=容量✖️负载因子。

举个栗子：

比如容量是16，负载因子是0.75，这样存到第12个元素的时候就会触发扩容；

那如果负载因子改成0.5，这样存到第8个元素就会触发扩容；

如果负载因子改成1，那这样只有存满16个元素才会触发扩容。

所以，

负载因子如果设置的太低，桶里的元素就会越稀疏，这样虽然查找速度会更快，但是会造成内存空间的浪费；

负载因子如果设置的太高的话，桶里的元素就会越密集，虽然节省空间，但是冲突也会变多，这样查找就会变慢。

0.75是一个折中的值，既不会让数组太过空旷，也不会让链表太长，在大多数场景下都能保持不错的性能。

RabbitMQ怎么实现延迟消息

Sat, 17 Jan 2026 18:19:27 +0000

在RabbitMQ中，实现延迟消息可以通过死信交换机（DLX）+过期时间（TTL）的方案，也可以采用RabbitMQ官方提供的延迟消息插件。

DLX+TTL。

主要步骤如下：

1.声明并创建普通交换机和普通队列，完成二者的绑定。

2.声明并创建死信交换机和死信队列，也完成二者的绑定。

3.指定当前普通队列的死信要转发到哪个DLX，以及要匹配哪个死信路由键。

4.不给普通队列配置任何的消费者，使普通队列只做消息暂存和过期，不消费。

5.在生产者发送消息时，为消息设置TTL，将消息发送到普通队列和普通交换机。

6当消息在普通队列的存活时间达到TTL后，过期的消息会被自动转发到DLX中，DLX再重新路由到死信队列，从死信队列中发送的消息就是延迟消息。

rabbitmq_delayed_message_exchange插件

主要步骤：

1.将插件放到RabbitMQ的plugins目录

2.执行rabbitmq-plugins enable rabbitmq_delayed_message_exchange命令启用插件

3.声明一个延迟交换机

4.声明一个普通队列并绑定该延迟交换机

5.生产者在发送消息时，设置消息投x-dlay:延迟时间(ms)

说说Java中的JIT

Sat, 17 Jan 2026 18:18:18 +0000

JIT（Just In Time）即时编译，是一种在程序运行时将字节码转换为机器码的技术。

JIT在Java程序运行的时候，如果发现了频繁执行的代码段，我们称之为热点代码，就会将这段热点代码编译成机器码，从而减少解释执行的开销。

JIT有CLient Compiler和Server Compiler两种编译类型，

其中，Client Compiler适用于客户端应用程序，主要用于快速启动的轻量级优化；

Server Compiler适用于服务端应用程序，主要用于长时间运行的重度优化。

说说Java中的Logging-Write-Barrier

Sat, 17 Jan 2026 18:17:05 +0000

Write Barrier可以理解为JVM在对象引用赋值操作中插入的一段AOP代码，通过这段代码，在应用程序运行期间，垃圾收集器可以感知到对象引用关系的变化，从而维护记忆集（RSet）、卡表（Card Table）等必要的数据结构，避免全堆扫描。

Write Barrier按时机分，有Pre-Write Barrier和Post-Write Barrier两种类型。

Pre-Write Barrier在对象引用改变前触发，用于记录引用变更前的状态；

Post-Write Barrier和Pre-Write Barrier相反，是在对象引用改变后触发，用于记录引用变更后的状态。

Logging是一种策略，在G1收集器中，Post和Pre Write Barrier都采用了Logging机制来实现，也就是先记录日志，后异步处理。

那为什么要用Logging这样一种策略呢？

主要是如果每次引用修改都直接去更新RSet这种复杂的全局数据结构，这样会严重拖慢应用线程，并可能会导致多线程下的伪共享问题。

如果采用Logging机制，将对象的引用变更记录丢给应用线程负责，让后台线程负责复杂的处理，使对象的引用变更记录和处理解耦，从而保证在GC正确的前提下，最大程度地减少对应用程序吞吐量的影响。

Java的CMS垃圾回收流程

Fri, 16 Jan 2026 17:20:13 +0000

1.初始标记（initial mark）

CMS会标记所有根对象直接可达的对象。

2.并发标记（Concurrent marking）

并发标记阶段，垃圾收集器和应用程序并发执行，从根对象直接可达的对象开始进行tracing，递归的扫描所有可达对象。

3.并发预清理（Concurrent precleaning）

并发预清理阶段会先分担一些重新标记阶段的工作，扫描卡表脏的区域以及新晋升到老年代的对象。

4.可中断的预清理阶段（AbortablePreclean）

可中断的预清理阶段也是先分担一些重新标记阶段的工作，和并发预清理阶段不同的是这个阶段可以中断。

5.重新标记（remark）

因为前几个并发阶段会导致引用关系发生变化，所有需要重新遍历一遍新生代对象、GC Roots和卡表等，从而对标记进行修正，需要花较长的时间来进行重新扫描。

6.并发清理（Concurrent Sweeping）

并发清理阶段，标记为不可达的对象会被清理。

7.并发重置（Concurrent Reset）

重置CMS内部的状态。

Linux系统中常用的日志文件

Fri, 16 Jan 2026 17:19:26 +0000

Linux系统中的日志文件通常都存储在/var/log目录下。

messages	记录大多数系统范围内的普通信息和错误消息
syslog	系统日志文件，记录系统范围内包括启动、内核事件设备信息等消息
auth.log	记录授权相关的日志，比如用户的登录与登出
kern.log	记录内核产生的日志信息
dmesg	记录设备和驱动程序的初始化信息，以及内核启动期间产生的消息
boot.log	记录系统启动过程中发生的事件
faillog	记录失败的登录尝试信息

Java中的继承机制

Fri, 16 Jan 2026 16:29:52 +0000

在Java中，允许子类复用父类的字段和方法，用extends关键字建立继承关系。

Java只支持单继承，也就是一个类最多只能有一个直接父类。

子类可以继承父类的public和protected成员；对于父类的private成员，子类只能通过父类提供的public/protected方法来间接地访问。

子类的构造方法执行之前必须先调用父类的构造方法。

如果父类存在无参数的构造方法，则编译器会自动加上super();

如果父类不存在无参数的构造方法，只存在带参数的构造方法，则子类必须显示地调用super(参数)，因为编译器默认插入的是无参的super()方法，会导致编译报错。

继承在带来代码复用的同时也带来了紧耦合问题。

子类在重写父类的方法时，只能放大或者保持方法的访问权限，不能缩小访问权限。

也就是说，

父类如果是public方法，则子类只能是public；

父类如果是protected方法，则子类可以是protected或者public。

因为在父类引用指向子类对象时，调用方是期望能访问到这个方法的，如果子类缩小了这个权限，就会导致调用方无法访问。

说说RabbitMQ的集群模式

Thu, 15 Jan 2026 17:21:36 +0000

RabbitMQ的集群主要分为标准集群、镜像集群和联邦集群三种。

标准集群

标准集群是多台RabbitMQ服务器通过网络连接组成一个集群，所有节点共享元数据，但是一个消息只存储在单个节点上。

在标准集群模式下，因为元数据是共享的，所以任何一个节点都知道消息在哪个节点上，可以实现负载均衡。

消息存储在某个节点上但是不会自动复制到其他节点。

镜像集群

和标准集群模式不同，镜像集群模式下，队列的消息会复制到多个节点上，如果主队列所在的节点发生故障，副本节点会自动接管，从而保证队列的可用性。

Federated 集群

通过Federated Exchange或Federated Queue实现消息的跨节点路由 / 复制，节点之间无需共享元数据，解决了标准 / 镜像集群无法跨广域网部署的问题。

在Linux系统中如何使用ssh进行远程登录

Wed, 14 Jan 2026 17:07:17 +0000

1.首先需要确保远程服务器和本地主机都安装了OpenSSH软件；

2.如果采用用户名为“Javaer_12”连接到远程主机"192.168.1.114"，可以输入以下指令：

`1`	`ssh Javaer_12@192.168.1.114`

3.第一次连接的时候可能会提示你确认主机的真实性，输入yes即可，再输入远程服务区的密码即可登录。

⚠️ 注意：只能输完整的 yes，输 y 无效

使用输入密码的方式进行登录，时间长了会感觉比较麻烦，这时可以考虑通过密钥验证的方式进行登录。

通过密钥进行登录的大概就两步：

先在本地生成ssh密钥对：

`1`	`ssh-keygen -t rsa`

再将公钥复制到远程服务器上：

`1`	`ssh-copy-id Javaer_12@192.168.1.114`

这样有时还是会感觉有点麻烦，可以使用.ssh/config文件进行配置：

1
2
3

Host my_server_name
	HostName 192.168.1.114
	User Javaer_12

接下来就可以通过输入ssh my_server_name来进行登录了。

整理在Linux系统中查看和管理系统服务的命令

Wed, 14 Jan 2026 16:46:44 +0000

在Linux系统中，可以使用systemctl命令来查看和管理系统服务。

`systemctl list-units --type=service`	查看所有服务的状态
`systemctl status <服务名>`	查看特定服务的状态
`systemctl start <服务名>`	启动服务
`systemctl stop <服务名>`	停止服务
`systemctl restart <服务名>`	重启服务
`systemctl enable <服务名>`	启用服务，设置为开机自启
`systemctl disable <服务名>`	禁用服务，取消开机自启

Linux 中服务名通常都是带.service后缀的（如nginx.service、redis-server.service），使用systemctl时省略.service 后缀，命令仍会生效。

什么情况下会触发Java的Full-GC

Wed, 14 Jan 2026 16:29:41 +0000

整理了以下5种可能会触发Java的Full GC的情况：

1.当老年代的空间不足并且无法通过老年代的垃圾回收以释放足够多的空间时，会触发Full GC来回收老年代中的对象。

2.在Java 8以前，如果永久代的空间不足，会直接触发 Full GC。在Java 8及以后，永久代被元空间取代，由于元空间手动设置了最大阈值，当内存耗尽时也可能会触发Full GC。

3.当显示地调用System.gc()方法时，JVM可能并不能保证立即执行Full GC，但是有可能会触发。

4.当新生代的to区放不下从eden区和from区拷贝过来的对象或者新生代的大对象或者长期存活的对象晋升到老年代时，如果老年代没有足够的空间来容纳这些对象，这个时候也会触发Full GC。

5.在要进行新生代GC的时候，如果根据之前的统计数据发现新生代的平均晋升大小比现在的老年代剩余空间还要大，也会触发 Full GC。

为了减少Full GC 的触发，可以考虑以下策略：

调整堆内存的大小，从而减少老年代空间不足的情况
增大新生代的大小，从而减少对象晋升到老年代的频率
设置合理的元空间大小，从而避免元空间过小导致的频繁Full GC

请解释一下Java中的强引用、弱引用、软引用和虚引用

Tue, 13 Jan 2026 16:57:03 +0000

强引用（Strong Reference）

这是最常见的引用类型。

只要一个对象有强引用指向它，即便是系统内存紧张，垃圾回收器也不会回收该对象。

软引用（Soft Reference）

软引用是用来描述一些还有用但是并非必需的对象，通常用于实现缓存机制，允许程序在不影响性能的情况下利用多余的内存。

当系统内存不足时，垃圾回收器会对软引用指向的对象进行回收，避免内存溢出。

弱引用（Weak Reference）

弱引用是比软引用更弱的一种引用类型，常用于防止内存泄露，允许缓存的键值对在不再使用的时候自动清除。

和软引用在系统内存充足的情况下不会被回收不同的是，弱引用只要被垃圾回收器发现只有它指向某个对象时，不管系统内存是否充足，这个对象都会被回收。

虚引用（Phanton Reference）

虚引用是最弱的一种引用类型，主要就是用来跟踪对象的垃圾回收状态。

如果一个对象只有虚引用，那么这个对象随时会被垃圾回收器回收。

虚引用必须和引用队列（ReferenceQueue）配合使用，否则虚引用就毫无意义。

解释一下Linux系统的权限管理机制

Tue, 13 Jan 2026 16:28:41 +0000

Linux中的权限管理机制主要是围绕用户和组的权限展开。

Linux中的文件和目录都是由：

所有者（user）、组（Group）、其他人（Others）

这三种实体来管理权限。

可以使用ls -l命令来查看文件的权限和所有者。

1.每个文件和目录都有一个所有者和一个所属组。

每个用户都有一个唯一的用户ID（UID），每个组也有一个ID（GID）。

一个用户可以属于多个组，但是一个文件只能有一个所有者和一个组属性。

2.权限可以使用符号来表示，也可以使用八进制来表示。

可读（r，read）、可写（w，write）、可执行（x，execute）

r对应八进制4，w对应八进制2，x对应八进制1，通过相加和可得出最终的权限数值。

在Linux系统中-如何设置文件的权限和拥有者

Mon, 12 Jan 2026 16:41:27 +0000

在Linux系统中，文件的权限可以通过chmod指令来设置，文件的拥有者可以通过chown 指令来设置。

1.设置文件的权限

`1`	`chmod 755 my_file`

设置my_file文件的权限为755

2.设置文件的拥有者

`1`	`chown user:group my_file`

将文件my_file的拥有者设置为user，所属的组设置为group

在Linux中，文件权限以读（r）、写（w）、执行（x）三个基本权限来表示。

权限分用户（u）、组（g）和其他用户（o）三类。

755表示的是所有者拥有rwx权限，组合其他用户拥有rx权限，没有w权限。

配置文件一般设置为644，脚本文件设置为755。

什么是RabbitMQ中的死信队列

Mon, 12 Jan 2026 14:44:12 +0000

在消息队列系统中，死信队列（Dead Letter Queue,DLQ）是一种处理无法正常消费的消息的机制。

RabbitMQ 中实现死信机制的核心是死信交换机（Dead Letter Exchange, DLX），绑定该交换机的队列就是死信队列。

死信队列是用来接收那些被拒绝的、过期的或者已经达到最大传递次数的消息。

可以通过给队列设置x-dead-letter-exchange 参数来指定死信交换机，搭配x-dead-letter-routing-key指定死信路由键，从而实现死信队列的绑定。

怎么在RabbitMQ中配置消息的TTL

Mon, 12 Jan 2026 14:17:02 +0000

TTL（Time To Live）表示消息在队列中存活的时间，主要用于防止消息在队列中无限积压，导致系统资源的耗尽。

配置TTL有两种方式，一种是队列级别的TTL，另外一种是消息级别的TTL。

1.在声明队列时通过设置x-message-ttl参数来指定队列中所有消息的TTL。

2.在发送消息时通过AMQP.BasicProperties属性指定单个消息的TTL。

RabbitMQ中的Prefetch参数

Sun, 11 Jan 2026 17:07:58 +0000

在RabbitMQ中，prefetch参数主要是用于限制消费者端可以同时预取并未确认消息的最大数量，帮助消费者端控制消息处理的流量。

举个例子说明一下：

如果prefetch的参数设置为1，那么消费者会在未确认消息之前，只预取一个消息，这样可以确保每个消息在被处理成功之后，才接收下一个消息，从而避免消息的积压和资源耗尽。

在负载均衡、避免内存溢出以及优先级处理这些场景下会用到prefetch参数的设置。

比如：

1.RabbitMQ默认轮询分发消息，消费者可以根据其处理能力进行动态地调整prefetch值，实现基于处理能力的动态负载均衡。

2.如果有大量未处理的消息堆积在内存中可能会导致内存溢出，这时通过设置一个较小的prefetch值可以避免这种情况。

3.配合RabbitMQ的优先级队列，设置prefetch值可以确保队列优先推送高优先级的消息，让其被及时处理。

注意⚠️：

prefetch仅在消费者手动确认消息模式下生效。

JVM的内存区域是怎么划分的

Sun, 11 Jan 2026 16:36:51 +0000

JVM的内存区域指的是JVM的运行时数据区。

主要分为方法区、堆、虚拟机栈、本地方法栈和程序计数器五个主要区域。

1.方法区（Method Area）

线程共享区域，存着类的结构信息、常量、静态变量。

2.堆（Heap）

最大的共享区，专门放对象和数组。

3.虚拟机栈（JVM Stack）

线程私有，存着局部变量、操作数栈、动态链接、方法出口信息、基本类型变量、对象引用。

4.本地方法栈（Native Method Stack）

线程私有，用来分配内存给非Java方法。

类似于虚拟机栈，专为JNI调用本地代码服务。

5.程序计数器（Program Counter Register）

每个线程都有一个独立的程序计数器，线程私有。

保存当前线程执行的Java 方法字节码指令的地方或者行号。

JIT编译后的代码存在哪

Sun, 11 Jan 2026 16:04:17 +0000

JIT（Just-In-Time）编译后的代码通常存放在代码缓存区（Code Cache）中。

JVM提供了如下参数用于调整Code Cache的大小和行为：

-XX:InitialCodeCacheSize	初始大小
-XX:ReservedCodeCacheSize	最大大小
-XX:+PrintCodeCache	打印Code Cache信息

Code Cache的默认大小依赖于JVM的版本和运行环境，通常有一个最大值。

Code Cache分为多个区域，分别存储不同级别的编译代码：

非方法代码	存储运行时的JVM调试代码或者模板代码
方法代码	存储普通JIT编译的代码
轮廓代码	存储优化级别更高的代码

说说Java中的常量池

Sat, 10 Jan 2026 17:02:58 +0000

Java中的常量池是一块用于存储运行时常量或者符号的区域。

主要有字符串常量池和运行时常量池。

字符串常量池用于存储字符串字面量，可以通过String类中的intern()方法复用常量池中的字符串对象，若不存在则将当前字符串对象入池。

Java6中的字符串常量池位于方法区中的永久代中，Java7及以后位于堆内存中的特殊区域。

在Java中，字符串的创建方式有两种，一种是直接使用字面量，另一种是使用new关键字。

运行时常量池存储的是每个类或者接口的Class文件编译时生成的常量信息。

需要说明的是，按照JVM的定义来说，字符串常量池逻辑上还是属于运行时常量池，只是因为字符串的高频使用，被单独抽离出来做了优化设计。

RabbitMQ的消息确认机制是怎么工作的

Sat, 10 Jan 2026 16:33:38 +0000

RabbitMQ的消息确认机制主要是用于确保消息的可靠传递，防止消息丢失。

通过发布确认和消费者确认来实现。

发布确认

当生产者发送消息到RabbitMQ时，可以选择开启发布确认模式，当RabbitMQ成功将消息入队/持久化之后，会发送一个ACK回复生产者，告知消息成功到达队列；仅当消息处理失败时会返回NACK。

如果生产者在合理的时间内没有收到ACK或者NACK，则可以重发消息。

消费者确认

消费者在处理完一条消息之后，必须发送一个ACK给RabbitMQ，告知RabbitMQ该消息已经处理完成，RabbitMQ在收到ACK之后会将该消息从队列中永久删除。

如果RabbitMQ在收到消费者ACK之前检测到消费者已经断开连接，则认为该消息没有被成功处理，RabbitMQ会重新发送给其他消费者消费。

整理Java中Object类的方法和作用

Sat, 10 Jan 2026 15:47:23 +0000

public boolean equals(Object obj)	用来比较两个对象是不是相等，默认比较的是内存地址。
public int hashCode()	返回当前对象的哈希值
public String toString()	返回对象的字符串形式
public final Class getClass()	返回对象运行时的类信息，反射的时候经常用到
public void notify()	唤醒一个正在等待当前对象的线程。必须在synchronized代码块中配合wait()一起使用
public void notifyAll()	唤醒所有在这个对象上等待的线程
public void wait()	当前线程挂起，等待别的线程来notify它，只能在同步块/同步方法中使用
public void wait(long timeout)	在wait方法的基础上加了个超时控制，过了时间就自己醒来
public void wait(long timeout,int nanos)	在wait()方法的基础上加了个更精细的超时控制，支持纳秒级的等待
protected Object clone()	拷贝当前对象，默认是浅拷贝
protected void finalize()	对象被垃圾回收之前会自动调用这个方法

Java中怎么判断对象是否是垃圾

Fri, 09 Jan 2026 16:00:00 +0000

主要是采用引用计数法和可达性分析算法两种方式来实现。

引用计数法（Reference Counting）

每个对象维护一个引用计数器，当引用计数增加时，计数器加1，减少时，计数器减1。

当引用计数器为0时，说明该对象不再被引用，此时可以被回收。

这种方法实现起来比较简单而且实时性好，但是无法处理循环引用的问题。

可达性分析算法（Reachability Analysis）

这是Java中的垃圾回收主要采用的方法。

通过一组成为“GC Roots”的对象出发，遍历所有可达的对象，对于一切无法通过GC Roots到达的对象，均可视为垃圾。

这种方法可以解决循环引用的问题，但是需要消耗一定的资源进行标记。

在Linux系统中-怎么检查系统的磁盘使用情况

Fri, 09 Jan 2026 15:15:00 +0000

检查系统的磁盘使用情况可以使用df和du这两个命令。

df命令

df（disk filesystem），用于查看磁盘文件系统的整体使用情况。

df -h

h表示human-readable，就是以人类可读的格式输出磁盘分区、已用空间、空闲空间、总空间和挂载点的信息。

du命令

du（disk usage），用于检查指定目录及其子目录的磁盘使用情况。

`1`	`du -sh /home/user`

-s显示目录的总大小，-h以人类可读的格式显示，合起来就是以人类可读的格式查看home/user目录的总大小。

du -a

显示目录和所有文件的大小。

解释一下NIO、BIO、AIO

Fri, 09 Jan 2026 14:45:00 +0000

NIO（Non-blocking I/O），非阻塞I/O模式，调用方在发起I/O操作后即使操作未完成，也能立即返回。

结合I/O多路复用技术，可以使一个线程同时管理多个连接。

适用于连接数多、高并发和高性能要求的场景。

BIO（Blocking I/O），传统的阻塞式I/O模式，调用方在发起I/O操作时会被阻塞，直到操作完成后才会继续执行。

适用于连接数较少，逻辑简单的场景。

AIO（Asynchronous I/O）异步I/O模式，调用方在发起I/O请求后，不需要轮询或者等待I/O操作完成，可以继续执行其他任务，操作系统或者底层库会在I/O操作完成后，通过回调或者事件通知的方式告知调用方。

适用于对响应时间要求较高的应用场景。

PO、VO、BO、DTO、DAO、POJO有什么区别

Thu, 08 Jan 2026 17:58:10 +0000

PO（Persistent Object）持久化对象，主要用于和数据库交互，是数据库数据在内存中的镜像。

VO（View Object）视图对象，和前端展示强相关，按需组装前端需要的字段。

BO（Business Object）业务对象，封装业务逻辑，包含业务处理方法，是业务层专用，业务层只操作BO，不直接碰PO/DTO。

DTO（Data Transfer Object）数据传输对象，屏蔽底层 PO 结构，可细分 ReqDTO（请求）和 ResDTO（响应），用于跨层或者跨服务传输数据。

DAO（Data Access Object）数据访问对象，负责和数据库打交道，隔离业务逻辑和数据操作，依赖PO，通过操作PO完成与数据库的交互。

POJO（Plain Ordinary Java Object）简单Java对象，最基础的Java类。

PO/VO/BO/DTO 本质上都是 POJO。

常见的调用链路：

前端请求 → Controller接收【ReqDTO】→ Service将ReqDTO转为【BO】→ BO调用【DAO】→ DAO操作【PO】与数据库交互 → Service将BO/PO转为【ResDTO/VO】→ Controller返回给前端

在RabbitMQ中-怎么确保消息不会丢失

Thu, 08 Jan 2026 17:15:44 +0000

为了确保消息不会丢失，可以从以下3个方面解决：

1.在创建队列的时候设置durable为true，发布消息的时候设置delivery为2，从而确保队列和消息都是持久的。

这样，就算是RabbitMQ服务器重启也不会造成消息的丢失。

2.开启发布确认模式，这样的话，生产者会等待服务器的确认响应，确保消息已经成功存储。

3.使用明确的消费者确认机制，当消费者处理完消息之后，向RabbitMQ发送确认，只有在RabbitMQ收到消费者发来的确认之后才会将消息从队列中删除。

Java中有哪些垃圾回收算法

Thu, 08 Jan 2026 16:54:37 +0000

Java中的垃圾回收算法主要有3种，分别是标记-清除算法、复制算法、标记-整理算法。

1.标记-清除算法

这种算法的逻辑其实很简单，就是先遍历一遍，把有用的东西都打个勾✅（标记），然后把那些没打勾的垃圾直接扔掉（清除）。

不过，这种算法存在一个缺点，就是会留下内存碎片。

2.复制算法

复制算法可以很好地解决内存碎片问题，这种算法是把内存一分为二，平时只用一半。

回收的时候，会把活着的对象全部复制到另一半去，然后把原来的那一半直接清空。

这种算法的优点是快，可以保证没有碎片，但是需轮流着一半的空间不能用，太浪费空间了。

3.标记-整理算法

标记-整理算法是老年代常用的算法。

对老年代的对象，因为存活的时间长，如果采用复制算法，需要复制一大堆，速度太慢；

但是，标记-清除又会产生碎片。

所以，标记-整理算法是先进行标记，然后把所有活着的对象往一端推，再把剩下的空间全部清空。

通过这种方式，既不会产生碎片，也不会浪费掉一半的空间，不过，把所有活着的对象往一端推这个整理的动作会比较耗时。

整理Linux文件系统中各个目录的作用

Thu, 08 Jan 2026 16:25:43 +0000

Linux文件系统采用的是层次化的树形结构。

/	根目录，系统的起点，包括所有其他目录
/bin	存放系统必需的二进制可执行文件
/boot	存放引导加载程序和内核等系统启动相关的文件
/dev	存放像硬盘、终端设备、虚拟机等存储设备文件，这些文件只是接口，不存储实际数据
/etc	存放系统配置文件(用户账号)和脚本(启动脚本)等等
/home	普通用户的主目录，每个用户会有一个单独的子目录
/lib	必需的共享库和内核模块
/media	挂载点，用于挂载像U盘和光盘这类可移除介质
/mnt	一种临时挂载点，用于系统管理员手动挂载文件系统
/opt	用于安装附加软件包，通常是第三方应用程序
/proc	存放系统内核和进程信息的虚拟文件系统
/root	root的主目录
/sbin	存放系统管理员使用的系统二进制文件
/tmp	临时文件目录，各种程序的临时存储空间
/usr	包含用户执行的应用程序和文件
/var	存放日志文件、邮件等这类经常变化的文件

JVM由哪些部分组成

Wed, 07 Jan 2026 16:43:37 +0000

JVM主要由类加载子系统（ClassLoader）、运行时数据区（Runtime Data Area）、执行引擎（Execution Engine）以及本地方法接口（Native Interface）4个部分组成。

JVM就像一个虚拟的“电脑”，能让Java程序在不同的操作系统上跑起来。

核心工作流程是：

编写好的Java代码在编译成class文件之后，

类加载器首先负责把class文件从磁盘或者网络中拉进来，放入到内存中；

运行时数据区主要用于存放代码和变量；

执行引擎像个翻译官，把Java的字节码转成机器码；

当需要调用C++之类的外部代码时，就通过本地方法接口来帮忙桥接。

Spring-Boot支持哪些嵌入Web容器

Wed, 07 Jan 2026 16:27:41 +0000

Spring Boot支持以下4种嵌入Web容器：

1.Tomcat

Spring Boot默认的嵌入式Web容器，Spring Boot会自动地将Tomcat内嵌到应用程序中，是一种广泛使用的轻量级、广泛使用的Servlet容器。

2.Jetty

Jetty比Tomcat更轻量，是一个高效的Web服务器和Servlet容器，通常用于嵌入式系统或对资源占用较为敏感的环境。

3.undertow

undertow支持异步IO和HTTP/2，是一个轻量级的高性能Web服务器和Servlet容器，适用于处理高并发的HTTP请求。

4.Netty

Netty是一个非阻塞的异步事件驱动框架，是Spring WebFlux的默认嵌入式容器，仅适用于响应式编程模型，适合高并发的响应式应用。

你知道Spring-Boot配置文件的加载优先级吗

Wed, 07 Jan 2026 15:59:34 +0000

优先级如下：

命令行参数> JAR包外的application-{profile}.properties> JAR 包外的application.properties>JAR包内的application-{profile}.properties>JAR包内的application.properties。

需要注意的是：

当application.properties和application.yml同时存在时，如果是相同的参数，最终生效的是application.properties中的配置。

在Linux系统中-如何进行磁盘配额管理

Wed, 07 Jan 2026 15:49:05 +0000

在Linux系统中进行磁盘配额管理的核心步骤：

1.安装磁盘配额管理工具quota

如果是Ubuntu/Debian系列的Linux系统，输入以下命令：

`1`	`sudo apt-get install quota`

如果是CentOS/RHEL系列的Linux系统，输入以下命令：

`1`	`sudo yum install quota`

2.编辑/etc/fstab文件，为需要启用配额的分区添加usrquota和grpquota选项。

`1`	`/dev/sda1 /home ext4 defaults,usrquota,grpquota 0 2`

3.为了使第2步的配置生效，需要重新挂载分区

`1`	`sudo mount -o remount /home`

4.生成配额文件aquota.user（用户配额文件）和aquota.group（组配额文件）并初始化配额数据库。

#c=创建配额文件，u=用户，g=组，m=强制检查，v=显示详细过程
sudo quotacheck -cugmv /home

sudo quotaon /home

5.使用edquota命令为用户或组设置软性和硬性限制。

`1`	`sudo edquota username`

RabbitMQ的交换机有哪几种类型

Tue, 06 Jan 2026 17:52:56 +0000

RabbitMQ是一个可实现异步通信和任务解耦的消息队列系统。

主要有Direct、Fanout、Topic、Headers这4种类型。

Direct	根据消息的routing key精确匹配binding key，只有完全匹配的消息才会被转发到对应的Queue	适合像日志系统这种需要精确匹配的场景
Fanout	不考虑routing key，直接将接收到的每一条消息都广播到所有绑定到它的Queue	适合广播消息，比如社交媒体的消息推送
Topic	根据消息的routing key和binding key的模式匹配决定消息的流转路径	适合需要根据特定模式进行消息路由的场景，比如订单系统
Headers	根据消息的头部属性来路由，提供更加复杂和灵活的路由策略	适合需要更复杂路由逻辑的场景，比如不同部门处理的邮件系统

操作系统的进程有哪几种状态

Tue, 06 Jan 2026 17:32:22 +0000

在操作系统层面，一个完整的生命周期中包含5种基础状态，分别是新建（New）、就绪（Ready）、运行（Running）、阻塞（Blocked/Waiting）、终止（Terminated）。这5种状态中，中间的就绪、运行、阻塞又是核心状态。

我们可以把进程的这5种状态的转换想象成去银行的柜台办理业务的流程：

新建状态下，操作系统正在为进程分配进程ID（PID）和进程控制块（PCB），相当于我去银行取好了号，正在填写个人信息，但此时并没有进入到等待大厅；

就绪状态就是只要CPU有空闲，进程就能马上执行，相当于我的材料这些都准备齐了，坐在等待大厅里等着叫号；

运行状态下，进程此时占用了CPU的资源正在执行指令，相当于叫到我了，我此时就在柜台办理业务；

阻塞状态就是进程执行到一半，需要等待某个I/O操作或者某个文件的输入完成后才能往下执行，此时就进入了阻塞状态，相当于业务办理到一半，发现我的身份证复印件没带，让我选择去附近打印室复印或者通知家人朋友送来，这个时候只能等复印件拿到手之后，才能重新排队继续办理，这时不能插队；

终止状态，进程执行完毕或者发生了异常退出，资源被回收，相当于业务办理完了或者和柜员拌嘴被保安赶走，柜员可以给其他人接着办理了。

在Linux系统中怎么排查文件占用问题

Tue, 06 Jan 2026 16:52:26 +0000

平常的办公中，我们用的比较多的是Windows系统，应该也遇到过想删除一个文件但是显示这个文件被某个应用程序占用的问题吧，这个时候我们可以根据提示打开任务管理器把这个程序关闭，就能够删除这个文件了。

那在Linux系统的命令行界面怎么排查文件的占用问题呢？

可以使用lsof命令。

这个命令可以列出当前打开的文件以及关联的进程。

1.如果需要查找某个特定文件被哪个进程占用，可以执行：

`1`	`lsof /path/to/username/file`

以上命令可以列出所有打开该文件的进程信息，像进程ID、用户、文件描述符等等。

2.如果需要查找某个特定端口被哪个进程占用，可以执行：

`1`	`lsof -i :portnumber`

3.如果想要查看某个特定用户打开了哪些文件，可以执行：

`1`	`lsof -u username`

4.当你找到了占用文件的进程ID(PID)之后，可以使用kill命令来终止这个进程：

`1`	`kill -9 PID`

使用Linux的top命令进行性能监控的步骤

Tue, 06 Jan 2026 16:26:35 +0000

使用top命令可以获取到CPU使用率、内存使用情况、运行中的进程等重要信息。

步骤：

1.在终端输入top命令，按Enter键

2.之后就能看到一个实时更新的数据表，该数据表主要包含以下信息：

系统信息	当前时间、系统运行时间、用户数和平均负载
进程摘要	总进程数、运行的进程数、睡眠的进程数
CPU状态	CPU的不同使用状态，比如：用户空间(us)、系统空间(sy)、空闲空间(id)
内存和交换空间	物理内存和交换内存的使用情况
进程列表	当前所有运行进程的信息，包括进程ID(PID)、用户、优先级、CPU使用率、内存使用率等

常用的JVM配置参数

Mon, 05 Jan 2026 15:48:48 +0000

-Xms	初始化堆内存大小
-Xmx	最大堆内存大小
-Xss	设置每个线程的栈大小
-XX:MetaspaceSize	初始化元空间大小
-XX:MaxMetaspaceSize	最大元空间大小
-XX:+HeapDumpOnOutOfMemoryError	当发生OOM时，生成堆转储
-XX:+PrintGCDetails	打印详细的垃圾回收日志
-XX:+UseG1GC	启用G1垃圾收集器
-XX:+UseConcMarkSweepGC	启用CMS垃圾收集器
-XX:+UseZGC	启用ZGC低延迟垃圾收集器

说说RabbitMQ的基本架构

Mon, 05 Jan 2026 15:37:48 +0000

RabbitMQ的架构有以下6个关键组件：

Producer	生产者	主要负责生产消息并发送给RabbitMQ
Exchange	交换机	生产者发过来的消息并不是直接投进队列，而是交给Exchange，让Exchange根据消息中的Routing Key来决定把它扔进哪个队列
Queue	队列	这是消息最终存放的地方，在这里等待被取走
Binding	绑定	把Exchange和Queue连接起来，告诉交换机这个消息需要扔进哪个队列
Consumer	消费者	从Queue中取出消息并处理
Virtual Host	虚拟主机	VHost之间是完全隔离的，互不影响，通常用于区分不同的业务线

如果把RabbitMQ比作快递物流系统，那么6个关键组件分别对应的角色如下：

生产者是发件人，交换机是快递分拣中心，队列就是快递仓库，绑定就是分拣规则表，消费者就是收件人，虚拟主机就是快递分公司。

注意⚠️：

一个消息可以被拷贝到多个Queue，但是一个队列里的消息只能被消费一次。

Spring-Bean一共有几种作用域

Mon, 05 Jan 2026 14:53:26 +0000

六种。

singleton	默认是单例，一个 Spring IOC容器的内部只有一个Bean实例
prototype	原型，每次获取都会新建实例
request	每个请求都会新建一个属于自己的Bean实例
session	一个http session中有一个Bean的实例
application	整个ServletContext生命周期里，只有一个Bean实例
websocket	一个WebSocket生命周期内只有一个Bean实例

request、session、application、websocket这四种作用域都是只存在于Spring Web应用中的。

整理一些可用来分析JVM性能的工具

Sun, 04 Jan 2026 16:32:39 +0000

jmap	一种用于生成堆转储的命令行工具，可以用于分析JVM的内存使用情况
jstack	一种用于生成线程转储的命令行工具，可以用于分析线程的状态
jstat	一种用于监控JVM统计信息的命令行工具，可提供实时的性能数据
MAT	一种用于分析堆转储文件的工具，可以帮助识别内存泄漏和优化内存使用
jconsole	可以监控JVM的内存使用，垃圾回收、线程、类加载等信息
VisualVM	可实时显示JVM的内存使用、垃圾回收类加载等信息
Arthas	一个强大的Java诊断工具，提供实时监控和分析的功能

聊聊RabbitMQ

Sun, 04 Jan 2026 16:07:46 +0000

RabbitMQ是一个开源的消息中间件。

如果没有RabbitMQ，系统A直接把数据传给系统B，这样当B忙不过来或者挂了的时候，A就会卡死或者造成数据丢失。

但是，如果有了RabbitMQ，系统A可以把数据传给RabbitMQ，而RabbitMQ则负责把数据暂存起来，再按照系统B的处理能力，稳稳地传送给B。

RabbitMQ主要有3大应用场景：

1.比如在实现用户注册功能时，通过引入RabbitMQ进行异步处理，可以提升响应的速度：

没有引入RabbitMQ时，在注册完之后，需要同步地发邮件和短信，这样用户可能需要等几秒钟才能看到“注册成功”。

引入RabbitMQ之后，把注册的信息写入数据库之后，可以直接把“发送邮件”和“发送短信”这两个任务扔给RabbitMQ，这样就能够立刻给用户返回“注册成功”。

2.我们平常网购的时候，应该也会注意到，买东西的次数多了，某宝或者某东、某多的积分也会相应增加。

这也就是下单场景的积分累加。

想象一下如果订单系统直接调用积分接口，一旦积分系统挂了，那订单也下不了了。

有个大佬说过这样一句话：

没有什么是加一层中间层不能解决的，如果有，那就再加一层。

所以，中间加个RabbitMQ，这样订单系统只需要把“我要下单”的消息发送给RabbitMQ，而积分系统什么时候恢复那就什么时候再去取消息，从而累加积分。

通过这样引入RabbitMQ，可以实现应用之间的解耦，从而降低系统的依赖。

3.在双十一的秒杀场景下，通常会有几百上千万的请求在一瞬间涌进来，这个时候数据库可能就直接崩了。

通过引入RabbitMQ，先把请求全部扔进RabbitMQ排队，后台系统再按照自己的节奏从RabbitMQ中拉取请求进行处理，从而实现流量削峰，保护数据库的作用。

你给我解释一下Linux系统中的内存泄露问题和排查的方法

Sun, 04 Jan 2026 15:30:40 +0000

在计算机程序中，当不再被使用的内存没有被程序释放，随着时间的推移，这些内存会逐渐累积起来，最后导致系统内存不足，这就是所谓的内存泄漏。

内存泄漏轻则导致程序性能下降，重则导致系统崩溃。

那么排查内存泄漏则有以下方法：

1.使用top或者htop命令监视系统的整体内存使用情况，来帮助识别具体哪个进程占用了过多的内存。

2.使用free命令查看系统内存的使用情况，包括总内存、已用内存、空闲内存、缓存内存。

3.使用ps命令列出进程的详细信息，包括内存的使用情况。

说说Spring-Boot-Actuator

Sun, 04 Jan 2026 14:33:48 +0000

Spring Boot Actuator是一个具有监控和管理功能的工具。

通过Actuator可以监控应用的健康状况、查看指标、跟踪请求、管理环境参数等等。

Actuator的优势：

1.开箱即用，可以很容易地与外部监控系统集成。

2.提供了大量预定义的端点，可以用于展示和操作应用的内部状态，并且还支持自定义端点，扩展现有的端点功能。

3.提供了关于应用、系统、JVM、内存、线程等丰富的信息。

4.支持端点的安全访问控制，可以限制哪些端点可以公开访问。

整理一些Linux的常用命令

Sat, 03 Jan 2026 16:40:32 +0000

文件管理

ls	列出目录的内容
cd	切换目录
cp	复制文件或者目录
mv	移动或者重命名文件或者目录
rm	删除文件或者目录
touch	创建空文件或者更新文件的时间戳
find	查找文件或者目录

权限管理

chmod	修改文件或者目录的权限
chown	修改文件或者目录的所有者
chgrp	修改文件或者目录的所属组

文本处理

cat	查看文件的内容
grep	搜索文本的内容
sed	流编辑器，主要用于文本的处理
awk	文本处理工具，适用于处理列数据

系统管理

ps	显示当前的进程
top	动态地显示系统资源的使用情况
df	显示文件系统的磁盘空间使用情况
du	显示文件或者目录的磁盘空间使用情况
kill	终止进程
shutdown	关机或者重启系统

网络管理

ping	检测网络的连通性
ifconfig/ip	配置网络接口
netstat	显示网络连接、路由表等信息
ssh	远程登录
scp	安全复制文件

压缩和解压

tar	打包和解包文件
gzip	压缩和解压文件
zip/unzip	压缩和解压文件

Java对象是怎么在虚拟机中存储的

Sat, 03 Jan 2026 16:19:53 +0000

Java对象在虚拟机中主要由对象头、对象实例和对齐填充三部分组成。

1.对象头中包含了对象的元信息和运行时数据。

对象头主要由Mark Word、类型指针和数组长度三部分组成。

其中，数组长度只有数组才有；

Mark Word主要用于存储运行时数据，会根据对象的状态动态变化；

类型指针指向对象对应的类的元数据，用于确定该对象的类型。

2.对象实例存储的是对象的实际数据，也就是类的字段。

3.为了满足内存一般情况下的8字节对齐要求，JVM可能会在对象的末尾添加填充字节。

至于存储位置，大多数的对象分配在堆中，堆也是JVM管理的内存中最大的一块区域。

说说Linux-CFS

Sat, 03 Jan 2026 15:53:48 +0000

Linux CFS（ Completely Fair Scheduler，全公平调度器）是一种用于替代O(1)调度器的进程调度算法。

CFS主要目的是使每个任务都能够按照其优先级，占用CPU的时间片段，尽可能公平地分配CPU资源。

CFS有以下特点：

1.每个任务都是按照优先级决定权重，进而根据权重分配CPU时间，尽量保证每个任务都能按比例公平地获得CPU资源。

2.使用虚拟运行时间（vruntime）来衡量每个任务的CPU时间，vruntime越低，优先级越高。

3.所有可运行的任务都存储在红黑树中，按照vruntime进行排序，其中最左节点也就是vruntime最小的节点更优先获得CPU的调度。

4.CFS支持多核调度，能够很好地处理从嵌入式系统到服务器集群的各种应用场景。

Spring是怎么解决循环依赖的

Sat, 03 Jan 2026 15:15:01 +0000

Spring是通过三级缓存机制来解决循环依赖的。

我们可以把这三级缓存想象成3个不同等级的“货架”：

其中，一级缓存存放的是成品货架，这里面都是完全初始化好，并且可以直接使用的Bean。

二级缓存存放的是半成品货架，这里面都是已经实例化好的，但是呢，还没有填充属性的Bean。

三级缓存存放的是工厂货架，这里放的就不是Bean了，而是一个可以生产Bean的工厂。

我们来理一下三级缓存解决循环依赖的流程：

假设A和B是相互依赖的，

首先，Spring先把A实例化出来，此时A还只是一个空壳，紧接着把一个可以获取A的工厂放到三级缓存里。

然后，A开始填充属性，这时发现需要B，所以就跑去创建B。

这时，B也实例化出来了，也开始填充属性，发现需要A。

然后，B就去一级缓存中寻找A，但是呢，没找到；所以又去二级缓存中寻找，也没找到；再跑去三级缓存中寻找，这下找到了。

这时，B就调用三级缓存中的工厂，拿到了A的引用。

为了保证是单例，只生产一次，B就把拿到的A放到二级缓存中，并把三级缓存中的工厂删掉。

B拿到了A后，B就创建完成了，入驻一级缓存。

A拿到B之后，A也可以创建完成，也可以入驻一级缓存。

说说Java程序的执行流程

Fri, 02 Jan 2026 16:32:54 +0000

Java程序的执行流程：

1.编写.java源代码文件。

2.使用javac编译器生成.class字节码文件。

3.通过java命令启动JVM，并指定主类。

4.JVM类加载器按需加载主类及运行所需的其他.class文件。

5.JVM定位到主类的main方法，开始执行其逻辑，作为程序的入口。

6.执行过程中，JVM通过解释执行和JIT即时编译，将字节码转换为机器码并执行。

7.运行期间，JVM对内存进行管理，回收不再使用的对象。

8.如果没有非守护线程运行，则触发JVM退出流程。

9.JVM销毁内部组件，释放资源，最终JVM进程退出。

如何在Linux系统中查看某个特定进程的内存使用情况

Fri, 02 Jan 2026 15:53:05 +0000

1.使用ps命令

举个例子，如果要查看进程ID为1527的进程的内存使用情况，可以使用如下命令：

`1`	`ps -p 1527 -o %mem,%cpu,vsz,rss`

其中，vsz表示虚拟内存的大小，rss表示常驻内存的大小。

2.使用top命令

要查看某个进程的内存使用情况时，可以依次输入top，再按f键进入域选择界面，再按N键就能显示内存的使用排序。

3.使用/proc文件系统

/proc提供了内核和进程的信息。

每个进程都有一个对应的目录，以ID为1527的进程为例，

/proc/1527/status包含VmSize虚拟内存大小和VmRSS常驻内存大小这些基本信息；

/proc/1527/statm包含进程的内存页面数。

JVM方法区会出现内存溢出吗

Fri, 02 Jan 2026 15:19:31 +0000

在Java8以前，方法区被实现在永久代中，永久代是一块固定大小地内存区域，这块区域不能进行动态地扩展。所以，如果加载的类过多或者常量池的数据过多，超出了永久代的限制，就会报永久代内存溢出的错误。

在Java 8及之后，方法区被实现在元空间中，不再使用堆内存，转向使用本地内存，元空间可以通过参数设置最大大小，但也会受物理内存的限制。

所以，如果加载的类过多或者大量动态生成类还是会报元空间内存溢出的错误。

Spring-Boot-2.x和1.x版本相比有哪些区别与改进

Fri, 02 Jan 2026 15:02:23 +0000

昨天说了Spring Boot 3.x和2.x版本相比有哪些区别与改进？，今天来看看Spring Boot 2.x和1.x版本相比有哪些区别与改进？

1.Spring Boot 1.x基于Spring Framework 4.x，不支持响应式编程；Spring Boot 2.x基于Spring Boot 5，引入了对响应式编程的支持。

2.Spring Boot 2.x对Tomcat、Jetty这些嵌入式Web容器的默认版本进行了升级，带来了对新HTTP标准的支持。

3.Spring Boot 2.x对底层组件和框架本身做了大量的性能优化，使得应用启动时间更短，运行性能更高，更加适合云原生应用和大规模的微服务架构。

4.Spring Boot 1.x中，Actuator端点是默认全部开启的，存在安全上的隐患，Spring Boot 2.x对Actuator进行了全面改进，在默认情况下，大多数端点是关闭的，开发者可以通过配置显示地启动需要的端点。

说说编译执行和解释执行的区别

Thu, 01 Jan 2026 17:35:59 +0000

编译执行是程序在执行之前，先通过编译器将源代码编译为机器代码，然后直接在CPU上运行；

解释执行是源代码在不经过编译器编译的前提下，直接在运行的时候通过解释器逐行翻译并执行。

常见的编译性语言有C和C++，而常见的解释性语言有Python。

编译执行的语言因为编译后的程序不需要在运行的时候再进行翻译，所以运行速度快。

但是，程序需要针对每个平台重新编译，跨平台性会更差一点。

而解释执行的语言在每个平台上都是通过相应平台的解释器来运行的，跨平台性好。但是每次执行的时候都需要进行动态的翻译和解释，所以运行速度更慢。

严格来说，JVM是结合了编译执行和解释执行的。

正常情况下JVM是解释执行的，不过，如果JVM发现某段逻辑执行的特别频繁，那么它就会通过JIT（Just In Time）即时编译将其编译成机器码，这样就是编译执行了。

Java是怎么实现跨平台的

Thu, 01 Jan 2026 17:02:43 +0000

跨平台指的是在不同的硬件或者操作系统上，Java代码在不需要针对不同的平台做对应的修改的前提下，都可以正常运行。

要实现这样一种一次编写到处运行的特性，主要靠的是JVM，即Java虚拟机。

和其他编程语言在编译后直接生成特定于某一操作系统的二进制01机器代码不同，Java程序在编译之后生成的是.class格式的字节码。

JVM为了屏蔽不同硬件或操作系统的底层细节，针对不同的平台做了对应的开发，可以实现将字节码翻译成特定平台上的机器代码并成功执行，这就使得同一份Java字节码可以在任意的支持JVM的平台上正常运行。

Spring-Boot-3.x和2.x版本相比有哪些区别与改进

Thu, 01 Jan 2026 16:05:33 +0000

1.Spring Boot 2.x基于Java EE，而Spring Boot 3.x迁移到了Jakartaa EE，一些核心的包名也从javax.*变更为jakarta.*了。

2.Spring Boot 2.x支持JDK8、11和17版本，而Spring Boot 3.x要求JDK版本最低为17。

3.Spring Boot 2.x 没有原生编译的内置支持，Spring Boot3.x则提供了对GraalVM Native Image的开箱即用支持，可以将Spring应用编译成本地的可执行文件。

4.Spring Boot 2.x仅支持基本的监控和追踪，Spring Boot 3.x引入了更完善的分布式追踪、日志关联和性能指标收集，支持OpenTelemetry标准，开发者可以借助Observability更好地监控和分析应用的运行状况。

5.Spring Boot 2.x支持Spring Security 5，在安全性上存在一定的局限性；Spring Boot 3.x增强了对Spring Security 6的支持，强化了身份认证、授权和安全配置的能力。

6.Spring Boot 2.x的依赖库和自动配置很强大，但是存在一些历史遗留的依赖和配置；Spring Boot 3.x对内部依赖进行了一些模块化的调整，对一些不再使用或者过时的库进行了清理。

什么时候@Async会失效

Thu, 01 Jan 2026 14:12:06 +0000

有多种原因可造成@Async失效：

1.@Async依赖于Spring AOP，如果是内部调用的话则会绕过代理对象，直接调用原始方法。

2.Spring AOP默认只会对public方法生效，对于非public方法则不会被代理，所以此时@Async是失效的。

3.如果Spring Boot的主类或者配置类上没有添加@EnableAsync注解，也就是没有显示启用异步功能，则Spring是不会为其生成代理的。

4.@Async依赖于Spring容器管理的Bean，如果是手动new的对象，并没有被Spring管理，则代理机制也是会失效的。

说一说Java中堆和栈的区别

Wed, 31 Dec 2025 16:04:55 +0000

栈主要用于存储局部变量和方法的返回地址、参数等调用信息。

堆主要用于存储对象实例和数组。

JVM的垃圾回收主要是针对堆空间的一个处理，而栈空间是不会被回收的。

在一次方法的调用过程中，调用的时候数据存入栈空间，当方法执行完之后，数据就被弹出释放，

不需要像堆空间一样等待GC进行回收，所以相对而言，栈空间的生命周期会比堆空间更短。

Spring-Boot工程启动以后-怎么将数据库中已有的固定内容打入到Redis缓存中

Wed, 31 Dec 2025 15:49:46 +0000

要想实现在Spring Boot工程启动之后，直接将数据库中已有的固定内容打入到Redis缓存中，首先需要确保实体类已经实现了Serializable接口，并且已经正确配置了RedisTemplate的序列化方式。

可以考虑使用CommanLineRunner或者ApplicationRunner接口，在应用启动完成后执行初始化逻辑；

也可以通过@PostConstruct注解，在Bean创建之后立即执行数据库加载。

在懒加载场景，可以使用@Cacheable注解，在首次调用方法时触发缓存写入，完成预加载。

说说Linux系统中crontab的工作原理

Tue, 30 Dec 2025 15:07:15 +0000

crontab是Linux系统中的一个定时任务调度器，能够允许用户在一个特定的时间执行某些任务。

crontab指令通常是由5个时间字段和1个命令字段组成：

5个时间字段分别是：

分钟	0~59
小时	0~23
日期	1~31
月份	1~12
星期几	0~7

其中，0和7都表示星期日。

如果想要在凌晨2点执行一个脚本，可以执行如下crontab指令：

`1`	`0 2 * * * /path/to/script.sh`

说一说Linux系统中进程和线程的区别

Tue, 30 Dec 2025 14:50:54 +0000

我们先明确定义：

进程是一个具有独立运行环境的程序实例，操作系统可以通过进程调度来管理CPU的时间分配。

而线程则是进程中一个单独的执行路径，并且一个进程中可以包含多个线程，这些线程共享进程的地址空间和其他资源。

主要区别在于：

1.进程是资源分配的基本单位，线程是CPU调度的基本单位。

2.进程与进程之间是相互独立的，也就是说一个进程的崩溃并不会对其他的进程造成影响。但是，线程之间因为是共享进程的资源的，所以，如果一个线程崩溃了，可能会导致整个进程的崩溃。

3.进程之间的切换开销是大于线程之间的切换的，因为线程是在同一进城内切换，所以会相对轻松点。

4.进程主要应用于Web服务器和数据库管理系统这些场景，线程则主要应用于多线程下载器和并发处理计算任务的场景，比如Java线程池等等。

在Linux中如何查看系统中内存、CPU和网络端口的使用情况

Tue, 30 Dec 2025 14:29:00 +0000

1.top命令

top命令可以实时地查看当前系统CPU使用率、内存使用率、进场ID等信息。

2.free命令

free命令可以查看系统中包括总内存量、已使用内存量和可用内存量等内存使用情况。

3.df命令

df命令可以查看系统中包括磁盘总容量、已使用空间和可用空间等磁盘使用情况。

4.iostat命令

iostat命令可以查看当前系统的CPU和I/O使用情况。

5.netstat命令

netstat命令可以查看系统中像本地地址、远程地址、连接状态等网络连接情况。

6.lsof命令

lsof命令可以查看当前系统中打开的文件和网络连接情况，像文件名、文件扫描符、进程ID、进程名等等。

说说CC攻击、DDOS攻击和网站数据库注入

Tue, 30 Dec 2025 14:15:03 +0000

CC攻击和DDOS攻击都是一种网络攻击方式。

CC 攻击是攻击者使用大量的机器或者网络中的代理服务器，向某个目标服务器发送大量的请求，以消耗服务器的带宽和资源，导致服务器瘫痪。

DDOS攻击（Distributed Denial of Service Attack）也是利用大量的计算机或者网络中的代理服务器，同时向某个目标服务器发送大量的请求，导致服务器瘫痪。

CC攻击其实是DDOS攻击的一种特定的形式，专门针对Web应用程序的一种攻击。

网站数据库注入则是一种利用Web应用程序漏洞的攻击方式。

这种攻击方式，攻击者通过将恶意SQL代码插入到Web应用程序的输入字段，对数据库进行未授权访问，从而破坏数据库的完整性、泄露敏感数据等等。

IDEA2023中新建Spring-Boot2.X版本的工程的方法

Tue, 30 Dec 2025 09:40:44 +0000

因为官方 Spring Initializr 服务（start.spring.io）已停止对 Spring Boot 2.x 系列旧版本的支持，仅保留 3.5.0 及以上新版本的分发，因此无法通过该服务获取 2.x 版本的项目模板。

并且Spring Boot 3.x 强制要求 Java ≥17，只有 2.x 系列支持 Java 8，所以会导致下拉框选不到Java8。

为了解决这个问题，需要将在IDEA 的 Spring Initializr 界面，点击顶部「Server URL」输入框，删除原有地址，输入阿里云的服务地址：

`1`	`https://start.aliyun.com`

之后就能够选择Java 8了。

点击Next之后，也能够选择2.X 系列的Spring Boot版本。

Linux系统的硬链接和软链接有甚区别

Mon, 29 Dec 2025 17:04:55 +0000

在Linux系统中，硬链接和软链接都是用于将一个文件链接到另一个文件。

主要区别如下：

1.硬链接是通过在文件系统中创建一个新的目录项指向同一文件的inode的位置来实现的，而软链接是通过在文件系统中创建一个包含指向另一个文件的路径的新文件来实现。

2.硬链接只能指向同一个文件系统内的文件，并不能跨文件系统创建，而软链接可以跨文件系统创建，并且可以指向任意类型的文件。

3.因为硬链接实际上指向的是同一inode，所以如果原文件被删除了，硬链接还是能够访问到原文件的内容；但是对于软链接来说，如果原文件被删除了，软链接也会跟着失效。

4.因为硬链接只是增加了一个新的目录项，所以对磁盘空间的消耗比软链接要更小。

什么是循环依赖

Mon, 29 Dec 2025 16:48:25 +0000

循环依赖是指两个或者多个bean之间相互引用，形成了一个闭环。

最典型的场景就是：

比如Spring正在创建Bean A，发现它依赖B，于是就去创建B，结果在创建B的时候，又发现它依赖A。

但是这个时候A正在创建中，还没有完全生成，这样B就拿不到A的引用，所以该咋办呢？

这里又分为构造器注入和Setter注入两种情况：

如果是构造器注入，那好办，Spring直接就给你抛出BeanCurrentlyInCreationException错误。

如果是Setter注入，Spring则是通过三级缓存机制来解决。

Kafka的索引设计有什么亮点

Mon, 29 Dec 2025 16:31:00 +0000

Kafka索引设计的亮点主要有以下4个方面：

1.kafka通过稀疏索引只存储每隔一定间隔的消息位置，而不是对每条消息都建立索引，这样可以大幅度减少内存的占用。

2.Kafka通过将日志文件拆分成多个段文件来存储，每个段文件中包含一个日志文件和对应的索引文件。

3.kafka为了降低磁盘的随机写入成本，采用顺序写入文件的方式，提升了写入性能。

4.Kafka为了避免逐个扫描，通过offset定位消息，再结合稀疏索引可以快速定位到近似位置后再进行顺序查找，从而保证高效地读取。

kafka中的时间轮实现

Mon, 29 Dec 2025 15:49:00 +0000

Kafka中的时间轮是一种用于实现定时清理、消息过期、心跳超时等功能的定时任务调度机制。

通过时间轮可以避免在大量的定时任务中进行逐个扫描，可以实现接近O(1)的延迟任务管理，降低了内存和CPU的消耗，比较适合管理大量短时和中长期的定时任务。

时间轮，它可以看成是一个环形数组，其中，每个槽表示一个时间间隔。

Kafka会在时间轮的每个槽中根据任务的到期时间放置延迟任务，当时间轮转到任务所在的槽时，就执行该槽内的任务。

如果存在到期未完成的任务，则会被重新分配到下一轮。

Kafka中关于事务消息的实现

Mon, 29 Dec 2025 15:06:48 +0000

Kafka的事务消息实现了消息在生产、传输和消费的过程中的“仅一次”传递，也就是所谓的Exactly Once语义。

Kafka的事务消息主要由事务协调器、幂等生产者和事务性消费这三个核心组件来实现。

事务协调器主要负责事务的启动、提交和终止管理，将事务状态记录到__transaction_state内部的主题；

为了确保同一事务的每条消息只写入一次，Kafka Producer通过Producer ID来作为事务的唯一性标志。

在消费的过程中，消费者可以选择只消费已提交的事务消息，从而确保数据的最终一致性。

我们可以理一下Kafka的事务消息流程：

首先是生产者向Transaction Coordinator请求启动事务；

接下来生产者为了保证幂等性，给每条消息都带上唯一的Producer ID和Sequence Number，开始向Kafka写入事务消息；

当所有消息都写入完成后，生产者开始向事务协调去发送commit或者abort请求提交或者终止事务。

最后，消费者为了实现最终的数据一致性，可以通过设置read_commited 隔离级别，只消费已提交的消息。

RocketMQ的事务消息有什么缺点你知道吗

Sun, 28 Dec 2025 17:01:10 +0000

RockMQ事务消息的缺点主要就以下几个方面：

从改造成本来看，RocketMQ需要改造它的原始逻辑来实现一个特定的接口，并且还需要在应用层来处理一个复杂的回查逻辑，从而确保回查不会重复或者丢失。

在可用性方面，由于RocketMQ的事务消息的实现是先发送半消息，如果MQ集群挂了，那么半消息就没法发送成功，后续的逻辑就无法再执行下去了，也就是说整个应用无法正常执行了。

还有一个缺点就是RocketMQ只支持单事务消息。

说说消息队列的推模式和拉模式

Sun, 28 Dec 2025 16:28:14 +0000

推模式是消息队列主动将消息从Broker推送给Consumer，这种模式它的实时性比较好，消息可以立即送达消费者，但是缺点就是决定权不在消费者手上，在高并发场景下容易造成消费者过载。

拉模式是消费者主动从消息队列中的Broker拉取消息，这种模式就是根据消费者自身的负载和消费能力来决定拉去消息的频率，这样就可以避免过载，但是这种模式的实时性比不上推模式，而且还会导致消息延迟。

RocketMQ和Kafka都选择了拉模式，对于拉模式无法保证实时性的缺点，他们采取的是长轮询的方式来解决。

主要是通过在消费者去Broker拉取消息时，当有消息存在的话，那自然就直接返回消息；当没有消息时，则保持连接，暂时hold住请求，之后如果在对应的队列或者分区有新的消息到来时就通过之前hold住的请求及时地返回消息。

消息队列如何处理消息堆积

Sun, 28 Dec 2025 15:14:44 +0000

在消息队列中，当消息的生产速度远远大于消费速度时，将会导致大量的消息积压在队列中，这样就会形成消息堆积。

那如何处理消息堆积呢？

一般来说，我们需要定位一下消费慢的原因，如果是bug则处理bug；如果是因为消费者自身的消费能力弱，则需要考虑提升消费者的消费能力。

那怎么提高消费者的消费能力呢？

1.可以考虑增加消费者的线程数量，提高消费者的并发消费能力；

2.如果是在分布式系统中，可以增加多个消费实例，从而提高消费速率。

3.优化消费者的代码，比如可以减少I/O操作或者使用批量处理等等。

上面这些是通过消费者端进行解决的方法，如果是从生产端解决的话，可以考虑对生产端进行限流，降低生产速率。

消息队列如何保证消息的有效性

Sat, 27 Dec 2025 17:56:38 +0000

为了保证消息的有效性，可采取如下方法：

1.为了确保消息按照生产者的发送顺序来消费，可以使用单个生产者向单个队列发送消息，再由单个消费者来处理消息。

2.对于像Kafka和RocketMQ这种支持分区的消息队列，可以通过Partition Key将消息发送到一个特定的分区。因为每个分区的内部都是有序的，这样一来就能保证具有相同Partition Key的消息都按照顺序来消费。

3.对于像RabbitMQ这种支持顺序队列的消息队列，因为消息在队列中的存储顺序和投递顺序都是一致的，如果使用单个顺序队列，那么消息也将按照顺序被消费。

消息队列如何处理重复消息

Sat, 27 Dec 2025 17:03:04 +0000

对于平常的业务而言，消息重复一般是不可避免的，我们只能在业务上来处理重复消息所带来的影响。

为了保证同一条消息无论被消费多少次，它的结果都是一样的，需要让消费者的处理逻辑具有幂等性。

为了实现幂等处理重复消息，可以给每条消息分配一个全局的唯一ID，当消费者接收消息时，先检查一下这个ID是否已经处理，如果已经处理则直接返回，如果没有处理，则执行逻辑并记录一下ID。

除了分配全局唯一ID，对于订单数据来说，还可以设计一个严格的状态流转（比如：待支付→已支付→待发货→已发货），这样在每次处理消息前对当前状态进行检查，看是否符合操作条件。

消息队列如何保证消息不丢失

Sat, 27 Dec 2025 16:15:36 +0000

为了保证消息不丢失，需要生产消息、存储消息和消费消息这三个阶段协同配合。

当生产者在发送消息时，需要通过消息确认机制来确保消息的成功到达。

我们知道存储在内存中的消息是断电不保存的，因此，为了避免消息因为服务器的宕机或者重启而丢失，需要在Broker收到消息后，将其持久化到磁盘中。

在消费者处理完消息后，需要向消息队列发送确认，如果没有收到消费者发送过来的确认，消息队列则需要重新投递该消息。

说一下消息队列有哪些模型

Sat, 27 Dec 2025 15:36:30 +0000

常见的消息队列模型主要有发布/订阅模型和队列模型（也称点对点模型）两种。

那什么是队列模型呢？所谓的队列模型，指的是消息从生产者发送到队列中，其中的消息只能被一个消费者消费一次，在消费者消费完之后，消息就在队列中被删除了。

而发布/订阅模型，则指的是生产者将消息发布到某个Topic中，这样所有订阅了这个主题的消费者都可以接收到这个消息，这种模型比较适用于像广播通知和实时推送这样的场景。

需要说明的是，RabbitMQ虽然具有发布/订阅模式，但是在本质上RabbitMQ还是通过同时将消息发送给多个队列来模拟出发布/订阅的效果，其底层依然是基于队列模型的。

而RocketMQ和Kafka则都是采用发布/订阅模型的。

解释一下什么是消息队列

Sat, 27 Dec 2025 14:42:56 +0000

消息队列是一种用于在分布式系统中，解耦发送方和接收方之间通信的异步通信机制。

消息队列通过引入一个broker作为中间缓冲区，然后将消息存储在broker中，接下来再由消费者从broker中读取和处理消息，从而实现异步通信。

消息队列常见的用途主要有：

1.生产者可以在发送消息之后立即返回，而消费者也可以在恰当的时机对消息进行处理。

2.在高并发的场景下，消息队列可以暂时存储大量的请求，平滑高峰期的流量，不至于使系统过载。

3.为了减少用户请求的响应时间，可以选择将不需要立即处理的任务放入消息队列中异步执行。

说说RocketMQ中关于事务消息的实现

Fri, 26 Dec 2025 16:46:06 +0000

在RocketMQ中，为了确保消息与本地事务的一致性，生产者会先将消息发送到RocketMQ的Topic中，这个时候消息的状态为半消息，对于消费者来说，还是不可见的。

接下来，生产者会执行本地事务：

如果本地事务成功了，生产者就会向RocketMQ执行commit操作，将半消息转变为正式消息，这样消费者就可见了。

如果本地事务失败了，生产者就会向RocketMQ执行Rollback操作，然后RocketMQ就会丢弃这个半消息。

如果生产者没有及时地执行commit或者rollback操作，那么RocketMQ就会定时地回查本地事务的状态，从而来决定是否commit或者rollback消息。

Java面向对象编程和面向过程编程的区别是什么

Fri, 26 Dec 2025 15:11:26 +0000

宏观层面上说：

面向对象是一种以对象为中心，以人类的思维方式来编写代码的编程风格，

而面向过程则是一种以过程或者说函数为中心，以计算机的思维方式来写代码的编程风格。

主要有以下几点区别：

面向对象主要关注的是对象之间的关系和交互，而面向过程主要关注函数的执行步骤和顺序。
面向对象的数据和行为都是封装在对象内部的，而面向过程的数据和函数却是分离的。
面向对象通过它的封装、继承和多态机制具有较高的复用性和可拓展性，而面向过程如果进行扩展可能需要修改已有的代码，复用性往往较低。
从适用场景上来说，面向对象很适合一些复杂系统的开发，而面向过程则只适用于一些简单的顺序性较强的小型项目的开发。

你知道为什么Java不支持多重继承吗

Fri, 26 Dec 2025 14:20:22 +0000

看看这张图，B和C都继承了A，D又继承了B和C。

想象这样一种场景，如果此时需要调用D中的一个定义在A的方法，但是呢，这个方法在B和C中存在不同的实现，这个时候就会出现歧义，从而无法抉择应该调用哪个。

说说Java中的不可变类。

Thu, 25 Dec 2025 17:47:54 +0000

Java中的不可变类指的是在对象完成创建之后无法被修改的类。

最典型的就是String，当然还有所有的基本类型的包装类，比如Integer、Long、Boolean等等。

如果要实现一个不可变类，至少需要同时满足以下5个条件：

为了防止子类继承父类之后添加了一些可变行为，导致不可变性遭到破坏，需要将类声明为final。
为了保证字段只能在构造阶段赋值，并且之后就不能通过外部进行访问或者修改，需要通过private final对字段进行修饰，将变量锁死。
需要通过构造函数一次性初始化所有字段。
可以提供getter方法，但是不能提供setter或者修改状态的方法。
如果类中含有可变对象的引用，需要确保在对象外部无法对这些引用进行修改。

这样一个不可变类，因为不能对它进行修改，所以多线程访问时不需要加锁，天生的线程安全。

又因为它的状态不可变，所以很适合作为缓存的key。

不过，实现这种不可变的代价就是比较费内存。

在Java中参数传递的方式是按值还是按引用

Thu, 25 Dec 2025 16:57:10 +0000

其实啊，在Java中，不管是基本数据类型还是引用数据类型，参数传递的方式都只有按值传递这一种。

对于基本数据类型，也就是（ byte, short, int, double, long, float, boolean, char）这8种，这些都是存储在栈内存中的。作为参数传递时，它们传递的都是值的副本，也就是基本数据类型的数值本身。

对方法中的参数进行操作时，并不会影响原始的变量。

对于引用数据类型，也就是所有的对象和数组，它们存储的是对象在堆内存中的地址，作为参数传递时，传递的是引用的副本。

方法内的修改可以通过引用影响到传入的对象的内容，但是并不会影响对象引用本身的地址。

说说看你认为Java的优势是什么

Thu, 25 Dec 2025 13:12:33 +0000

我认为Java的优势主要有以下几点：

1.因为有JVM这个充当翻译官的角色存在，程序员编写的代码编译成字节码后，不管是在Windows、Linux还是Mac系统上，JVM都可以把它翻译成机器可以读懂的语言，也就是可以实现跨平台，在企业的开发中，便于部署。

2.与C++需要手动的申请以及释放内存不同的是，Java自带了垃圾回收机制（GC），可以实现自动在后台帮程序员打扫内存垃圾，这样的话程序员的精力可以更多的倾向于业务逻辑。

3.Java的生态圈十分的庞大，可以说不管你想做什么功能，基本上你都能找到像Spring全家桶那样现成的并且是成熟的开源库，这样你就不用重复的去造轮子。

4.与面向过程的编程语言不同，Java是一种面向对象的编程语言，具备封装、继承和多态这3个特性。这种面向对象的特性，使得企业在开发和维护那种比较大规模、并且复杂度较高的系统时会相对容易一些。

什么是Java的多态特性

Wed, 24 Dec 2025 18:25:20 +0000

Java的多态指的是父类的引用指向子类的对象，使得在调用同一个方法时，会执行子类自己的实现。

通常来说，多态有3个必要条件。

1.要有继承关系，比如子类继承父类，或者实现关系，比如类实现接口；

2.子类需要重写父类的方法；

3.父类的引用指向子类的对象，换句话说就是把子类类型的对象赋值给父类类型的引用变量，也就是向上转型。

在面试的时候，有些面试官可能会问你多态的作用，多态的作用就两个：

一个是解耦，也就是调用方只依赖父类或者接口，并不会依赖它的具体实现。

另一个是可拓展，就是说可以在完全不修改原有代码的情况下新增一个子类。

多态性的实现方式

在面向对象的编程中，多态性有编译时多态和运行时多态两种实现方式。

编译时多态也称作静态多态，通过方法重载来实现，Java编译器会在编译时根据方法调用时传入的参数类型和数量来决定具体调用哪一个重载方法。

运行时多态也称作动态多态，通过方法重写来实现，当父类的引用调用方法时，在运行时会根据对象的实际类型来决定实际执行的子类重写之后的方法。

其中，

方法重载指的是同一个类的多个方法，它们的名称相同但是参数列表不同。

方法重写指的是子类重写了父类的一个或者多个方法。

Java中的Exception和Error有什么区别

Wed, 24 Dec 2025 16:50:46 +0000

在Java中，Exception和Error两者都是Throwable类的子类。

总体上来说，Exception是指可以被处理的程序异常，属于业务逻辑的范畴，常见的异常有NullPointerException和IOException等等；

而Error则指的是系统级的不可恢复的错误，错误出现以后一般就意味着进程需要终止或者重启，常见的错误有OutOfMemoryError、StackOverflowError等等。

如果细分的话，Exception又可以分为Checked Exception和Unchecked Exception，也就是受检异常和非受检异常。

常见的受检异常有IOException和SQLException，它们都是从Exception继承过来但是并不继承RuntimeException，在编译的时候必须使用try-catch块或者throws声明进行抛出这样的显式处理。

而非受检异常如NullPointerException和IndexOutOfBoundsException都是继承自RuntimeException，它们就不需要进行显式的处理，而是运行的时候才会抛出。

异常处理时需要注意的点：

1.如果什么异常都使用通用Exception，而不是特定的异常，那么其他同事在分析这段代码时就无法一眼看出这段代码实际想要捕获的异常。

所以，尽量不要捕获类似于Exception这样的通用异常，而应该捕获特定的异常。

2.如果我们在捕获异常之后不把异常进行抛出或者使用catch之后再用e.printStackTrace()输出一个标准错误流，这样操作的话也许这只是一个非常简单的bug，但是你仍然不知道是哪里出错了以及出错的原因。

所以，我们可以按需自定义一定的格式，将详细的信息输入到日志系统中，这样的话便于后续进行错误的排查。

3.想象这样一种场景，如果一个方法，这个方法内部调用了其他好几个方法，现在这个最开始的方法的某个参数传入了一个null值，但是，你并没有立刻处理这个情况，而是在这个最开始的方法调用了好几个方法之后才爆出这里其实最开始就有一个空指针。

这样就会造成其实你明明只需要在最开始只抛出一点点信息就能够定位到这个错误所在的地方，但是当最开始的方法调用了其他好几个方法之后你再抛出的可能就是很多的堆栈信息。

因此，最好不要延迟处理异常。

4.try-catch中的代码会影响JVM对代码的优化，因此，使用try-catch块时，不推荐try住一大段代码，而是在必要的代码段使用try-catch，也就是说try-catch的范围应该尽量小。

5.在控制程序的流程这一块，我们一般采取的原则是能用if/else语句来控制的话就不要用异常，直白点说就是不要通过异常来控制程序的流程。

6.在finally中return或者处理返回值往往会发生覆盖try中的return的情况，因此，最好不要在finallly中处理返回值或者return。

Java中的序列化和反序列化是什么

Wed, 24 Dec 2025 15:37:56 +0000

先来说说序列化，序列化是把内存中的对象转变成二进制的数据，通过这种形式才能存储到硬盘或者发送给别人。

再来说说反序列化，由于硬盘和网络都只认识二进制的0和1，不认识Java对象，所以必须进行转换，把二进制的数据变回内存中的对象。

在具体的实现细节上，有怎么做、怎么防、怎么稳这3个问题面试官比较喜欢问。

对于怎么做这个问题，一个类要想实现序列化，就必须实现Serializable接口，这个接口就相当于一个许可证。

至于怎么防，如果有些像密码这种的字段，它不想被保存下来，我们可以通过加上一个transient关键字，这样的话，序列化的时候就会自动跳过这些字段。

对于怎么稳，为了防止你修改了代码之后，在读取旧数据时发生报错，可以加上一个serialVersionUID版本号，这个版本号就相当于一个文件的身份证或者指纹。

这个serialVersionUID可以用来验证序列化的对象和反序列化之后对应的对象的ID两者是否一致。

举个例子说明一下：

比如，如果在没有定义一个serialVersionUID的前提下，接着序列化一个对象，在反序列化之前，在对象中增加了一个成员变量使得对象的类结构发生了改变，这个时候进行反序列化就会失败。原因就是serial VersionUID已经不一致了。

八股 on Coder_Studio

Spring Boot + Vue 前后端联调踩坑记录

别再搞混了！Redis、Jedis、Lettuce、Spring Data Redis、Redisson、Spring Session Redis 一次讲透

一篇搞懂：Java包名、Maven artifactId、Spring application.name到底有啥区别？

Java包名 com.codeedgexu.codeedgebackend

作用

小贴士

Maven artifactId codeedge-backend

作用

小贴士

application.yml文件中的codeedge-backend

作用

小贴士

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

设计方案

定好每一层的职责

缓存预热

缓存雪崩、击穿、穿透

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

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

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

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

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

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

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

为什么登录必须用 Token？

Token 的工作流程

Token 的作用

Token 和 Session 的区别

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

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

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

自增ID + Base62编码

小贴士

哈希算法+截取

随机字符串生成

为什么要用短链接？

1. 短信的字数限制

2. 防拦截、防屏蔽

3. 数据统计和追踪

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

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

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

小贴士

ThreadLocal内存泄漏问题

Java中的4种引用强度

ThreadLocalMap的Entry结构

怎么避免内存泄漏

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

7层OSI参考模型

7. 应用层

6. 表示层

5. 会话层

4. 传输层

3. 网络层

2. 数据链路层

1. 物理层

4层TCP/IP模型

5层教材简化模型

举个例子

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

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

(3) 客户端渲染页面

每层对应的协议

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

事务的四大特性

隔离级别

传播行为

小贴士

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

场景梳理

设计思路

服务层面

数据层面

高并发优化

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

场景梳理

实现方案

为什么选Redis？

为什么选ZSet？

Java包名 `com.codeedgexu.codeedgebackend`

Maven artifactId `codeedge-backend`

`application.yml`文件中的`codeedge-backend`

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

`maxmemory` 参数

设置 `maxmemory`的两种方式

1. `noeviction`

`volatile-lru`

`volatile-lfu`

`volatile-ttl`

`volatile-random`

`allkeys-lru`

`allkeys-lfu`

`allkeys-random`