职场和发展 on Coder_Studio

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

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

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

LangChain4j结构化输出

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

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

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

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

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

TokenStream + SSE

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

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

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

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

Flux & Reactor

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

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

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

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

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

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

一张图搞懂

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

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

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

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

一句话：

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

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

为什么登录必须用 Token？

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

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

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

Token 的工作流程

Token 的作用

Token 和 Session 的区别

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

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

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

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

面试官问：

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

为什么用SSE做流式输出？

一句话：

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

类比：

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

SSE流式输出的原理

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

完整的流程就是：

客户端发起请求

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

服务器建立长连接

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

服务器持续推数据

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

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

客户端解析数据

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

连接结束或自动重连

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

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

为什么不用WebSocket？

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

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

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

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

面试官问：

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

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

两个字：重定向。

用户点击短链接

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

浏览器请求短链接服务器

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

服务器查映射关系

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

服务器返回重定向响应

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

浏览器自动跳转

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

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

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

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

自增ID + Base62编码

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

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

小贴士

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

哈希算法+截取

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

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

随机字符串生成

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

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

为什么要用短链接？

1. 短信的字数限制

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

2. 防拦截、防屏蔽

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

3. 数据统计和追踪

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

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

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

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

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

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

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

类比一下工厂招工：

不用线程池

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

用线程池

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

线程池的7个核心参数

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

1. corePoolSize：核心线程数

工厂的正式工数量。

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

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

2. maximumPoolSize：最大线程数

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

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

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

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

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

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

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

4. unit：时间单位

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

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

5. workQueue：工作队列

工厂的待办任务队列。

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

6. threadFactory：线程工厂

给工厂的工人起名字的。

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

7. handler：拒绝策略

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

线程池的执行流程

提交新任务

工厂来了一个新任务；

判断核心线程数

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

判断工作队列

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

判断最大线程数

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

执行拒绝策略

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

任务执行完

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

空闲线程回收

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

4种默认拒绝策略

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

ThreadPoolExecutor 的构造方法

import java.util.concurrent.*;

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

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

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

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

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

面试官上来就问：

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

一句话：

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

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

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

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

1. 静态变量

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

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

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

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

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

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

2. 静态方法

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

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

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

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

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

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

3. 静态代码块

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

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

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

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

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

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

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

小贴士

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

4. 静态内部类

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

静态内部类的作用是：

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

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

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

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

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

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

小贴士

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

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

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

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 压力，又能保证安全可控。

【面试真题拆解】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();
            }
        }
    }
}

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

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

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

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

`maxmemory` 参数

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

设置 `maxmemory`的两种方式

配置文件 redis.conf：

1
2

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

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

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

Redis 的8种内存淘汰策略

可以分为两大类：

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

1. `noeviction`

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

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

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

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

`volatile-lru`

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

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

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

`volatile-lfu`

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

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

`volatile-ttl`

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

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

`volatile-random`

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

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

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

`allkeys-lru`

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

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

`allkeys-lfu`

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

`allkeys-random`

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

LRU vs LFU，到底有啥区别？

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

举个例子

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

键B今天被访问1次。

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

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

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

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

Java IO流的分类

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

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

字节流

什么是字节流？

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

字节流的核心类

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

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

举个例子

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

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

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

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

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

字符流

什么是字符流？

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

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

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

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

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

字符流的核心类

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

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

举个例子

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

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

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

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