小菜鸟

重导和管道

发表于 2022-02-04 更新于 2025-08-06 分类于 linux 阅读次数： Valine：
本文字数： 2.7k 阅读时长 ≈ 2 分钟

Shell 重定向与管道：数据流转的核心工具

在 Shell 中，重定向和管道是处理命令输入输出的强大工具，能够灵活控制数据的来源和去向，是实现复杂命令组合和自动化任务的基础。本文将详细解析重定向和管道的用法及实际应用。

重定向：控制命令的输入与输出

重定向通过改变命令默认的输入 / 输出位置（如终端），实现数据写入文件、从文件读取等功能。常用的重定向符号包括 >、>>、< 等。

输出重定向：`>` 与 `>>`

（1）覆盖输出 `>`

作用：将命令的输出结果覆盖写入到指定文件（若文件不存在则创建，若存在则清空原有内容）。
语法：命令 > 文件名

示例：

# 将当前目录列表写入 dir_list.txt（覆盖原有内容）
ls -l > dir_list.txt

# 将系统时间写入 time.log
date > time.log

（2）追加输出 `>>`

作用：将命令的输出结果追加写入到指定文件（保留原有内容，新内容添加到末尾）。
语法：命令 >> 文件名

示例：

阅读全文 »

MySQL查询状态

发表于 2022-02-02 更新于 2025-08-17 分类于 MySQL 阅读次数： Valine：
本文字数： 2.1k 阅读时长 ≈ 2 分钟

MySQL 查询状态详解：通过 `show full processlist` 解析线程行为

MySQL 中，每个连接线程在查询周期内会处于不同状态，这些状态反映了线程当前的工作内容（如等待请求、执行查询、排序结果等）。通过 show full processlist 命令可查看所有线程的状态，是诊断查询阻塞、性能瓶颈的重要工具。

查询状态的查看方式

使用以下命令查看线程状态：

-- 显示所有线程的简要信息（默认只显示前100条）
show processlist;

-- 显示所有线程的完整信息（包括完整SQL）
show full processlist;

输出结果包含以下关键列：

Id：线程 ID（可用于 kill 命令终止线程）。
User：执行该线程的用户。
Host：客户端主机。
db：当前操作的数据库。
Command：线程执行的命令类型（如 Query、Sleep）。
Time：线程处于当前状态的时间（秒）。
State：线程的具体状态（核心关注字段）。
Info：执行的 SQL 语句（show full processlist 显示完整内容）。

常见查询状态及含义

1. Sleep

阅读全文 »

责任链模式

发表于 2022-01-25 更新于 2025-08-19 分类于设计模式阅读次数： Valine：
本文字数： 4.5k 阅读时长 ≈ 4 分钟

责任链模式（Chain of Responsibility Pattern）：请求的链式传递与处理

责任链模式是行为型设计模式的一种，核心思想是将多个请求处理器串联成一条链，使请求沿着链传递，直到被某个处理器处理为止。这种模式通过分离请求的发送者和接收者，实现了两者的解耦，本质是 “分离职责，动态组合处理流程”。就像公司的审批流程 —— 请假申请会依次经过组长、部门经理、总经理审批，每个环节若有权限处理则审批，否则传递给下一级，核心是 “链式传递，各司其职”。

责任链模式的核心结构

责任链模式通过两个核心角色实现请求的链式处理，结构简洁且灵活性高：

抽象处理器（Handler）

定义处理请求的接口，声明处理方法（如handleRequest()），并持有下一个处理器（successor）的引用。
提供设置下一个处理器的方法（如setSuccessor()），用于构建责任链。
示例：Approver（审批者抽象类，声明approve(Request request)方法）。

具体处理器（ConcreteHandler）

实现抽象处理器接口，处理自身职责范围内的请求：
- 若能处理请求，则直接处理；
- 若不能处理，则将请求传递给下一个处理器（successor）。
示例：TeamLeader（组长）、DepartmentManager（部门经理）、GeneralManager（总经理）。

代码实现示例

以 “请假审批流程” 为例，展示责任链模式的实现：不同天数的请假申请由不同层级的审批者处理（组长批 1-3 天，部门经理批 4-7 天，总经理批 8 天以上），申请会沿责任链传递直到被处理。

1. 抽象处理器与请求类

// 请求类：封装请假信息
public class LeaveRequest {
    private String employee; // 员工姓名
    private int days;        // 请假天数

    public LeaveRequest(String employee, int days) {
        this.employee = employee;
        this.days = days;
    }

    public String getEmployee() { return employee; }
    public int getDays() { return days; }
}

// 抽象处理器：审批者
public abstract class Approver {
    protected Approver successor; // 下一个审批者

    public Approver(Approver successor) {
        this.successor = successor;
    }

    // 设置下一个审批者
    public void setSuccessor(Approver successor) {
        this.successor = successor;
    }

    // 处理审批请求（抽象方法，由子类实现）
    public abstract void approve(LeaveRequest request);
}

2. 具体处理器（各级审批者）

// 具体处理器1：组长（处理1-3天请假）
public class TeamLeader extends Approver {
    public TeamLeader(Approver successor) {
        super(successor);
    }

    @Override
    public void approve(LeaveRequest request) {
        if (request.getDays() <= 3) {
            // 组长可处理，直接审批
            System.out.printf("组长批准%s请假%d天%n", 
                request.getEmployee(), request.getDays());
        } else if (successor != null) {
            // 无法处理，传递给下一级
            successor.approve(request);
        } else {
            System.out.println("无人处理该请求");
        }
    }
}

// 具体处理器2：部门经理（处理4-7天请假）
public class DepartmentManager extends Approver {
    public DepartmentManager(Approver successor) {
        super(successor);
    }

    @Override
    public void approve(LeaveRequest request) {
        if (request.getDays() <= 7) {
            System.out.printf("部门经理批准%s请假%d天%n", 
                request.getEmployee(), request.getDays());
        } else if (successor != null) {
            successor.approve(request);
        } else {
            System.out.println("无人处理该请求");
        }
    }
}

// 具体处理器3：总经理（处理8天以上请假）
public class GeneralManager extends Approver {
    public GeneralManager(Approver successor) {
        super(successor);
    }

    @Override
    public void approve(LeaveRequest request) {
        // 总经理可处理所有超出部门经理权限的请求
        System.out.printf("总经理批准%s请假%d天%n", 
            request.getEmployee(), request.getDays());
    }
}

3. 客户端使用（构建责任链并处理请求）

public class ChainOfResponsibilityDemo {
    public static void main(String[] args) {
        // 构建责任链：组长 → 部门经理 → 总经理
        Approver generalManager = new GeneralManager(null); // 链尾，无下一级
        Approver deptManager = new DepartmentManager(generalManager);
        Approver teamLeader = new TeamLeader(deptManager);

        // 处理不同天数的请假请求
        LeaveRequest request1 = new LeaveRequest("张三", 2); // 2天（组长处理）
        LeaveRequest request2 = new LeaveRequest("李四", 5); // 5天（部门经理处理）
        LeaveRequest request3 = new LeaveRequest("王五", 10); // 10天（总经理处理）

        teamLeader.approve(request1);
        teamLeader.approve(request2);
        teamLeader.approve(request3);
    }
}

输出结果

1
2
3

组长批准张三请假2天
部门经理批准李四请假5天
总经理批准王五请假10天

责任链模式的核心优势

请求发送者与接收者解耦
发送者只需将请求交给责任链的第一个处理器，无需知道具体由哪个处理器处理，减少了对象间的直接依赖。
动态组合责任链
责任链的结构可动态调整（如新增审批环节、改变审批顺序），只需修改处理器间的引用关系，无需修改发送者或处理器的逻辑。
单一职责原则
每个处理器仅负责自身职责范围内的请求，职责清晰，便于维护和扩展（如新增 “总监” 审批者只需添加新的具体处理器）。
灵活性高
可根据需求灵活调整链的长度和处理逻辑，支持请求的部分处理或全链路传递。

适用场景

多对象可处理同一请求，但处理者不确定
如：
- 审批流程（请假、报销）：不同金额 / 天数由不同层级处理。
- 异常处理：不同类型的异常由不同的异常处理器处理。
- 日志系统：不同级别的日志（DEBUG、INFO、ERROR）由不同的日志处理器输出。
需要动态指定请求处理流程
如过滤器链（Filter Chain）：Web 开发中，请求会依次经过多个过滤器（如权限校验、参数过滤、日志记录），每个过滤器可决定是否继续传递请求。
避免请求发送者与多个处理者直接耦合
如 GUI 事件冒泡：按钮点击事件会从组件向上传递到父容器，直到被处理或到达顶层容器。

优缺点分析

优点

解耦性好：发送者无需知道具体处理者，处理者也无需知道请求的来源。
灵活性高：可动态调整责任链的结构和处理顺序。
扩展性强：新增处理者只需实现接口并加入链中，对现有代码无侵入。

缺点

请求可能未被处理：若责任链中没有处理器能处理请求，请求可能 “丢失”（需在链尾添加默认处理器避免）。
性能损耗：请求可能需要经过多个处理器才能被处理，尤其是长链场景。
调试难度增加：请求的传递路径不直观，排查问题时需跟踪整个链的执行流程。

经典应用案例

Java Servlet 的过滤器链（FilterChain）
Servlet 规范中的FilterChain是责任链模式的典型实现：请求会依次经过所有注册的Filter（过滤器），每个过滤器可处理请求或传递给下一个过滤器，最终到达Servlet。
Spring 的拦截器链（HandlerInterceptor）
Spring MVC 的拦截器链允许在请求处理前、处理中、处理后执行逻辑，拦截器通过preHandle()、postHandle()等方法构成责任链，可决定是否继续传递请求。
日志框架的处理器链
如 Logback 的Appender链：日志事件会被传递给多个Appender（如控制台、文件、数据库），每个Appender可处理日志或继续传递。
事件冒泡机制
GUI 框架（如 Swing、Vue）中的事件冒泡：用户操作事件（如点击）会从触发组件向上传递到父组件，直到被处理或到达顶层容器。

总结

责任链模式通过将请求处理器串联成链，实现了请求发送与处理的解耦，支持动态组合处理流程。其核心价值在于分离职责并允许请求沿链传递，特别适合审批、过滤、事件处理等场景。使用时需注意避免责任链过长导致的性能问题，并确保每个请求都能被处理（如在链尾添加默认处理器）

连接数问题

发表于 2022-01-24 更新于 2025-08-14 分类于 MySQL 阅读次数： Valine：
本文字数： 3.3k 阅读时长 ≈ 3 分钟

MySQL 连接数问题深度解析：从错误原因到根治方案

“too many connections” 错误是 MySQL 中常见的连接数超限问题，表面原因是当前连接数超过了 max_connections 限制，但本质往往是连接管理不当或应用设计缺陷。本文将从错误原理、诊断方法到优化方案，全面解决连接数过多的问题。

“too many connections” 错误原理

MySQL 对同时建立的连接数有上限控制（由 max_connections 参数定义），当新请求的连接数超过该值时，会拒绝连接并抛出错误：
ERROR 1040 (08004): Too many connections

连接数上限的限制因素

max_connections 并非可以无限调大，受以下因素制约：

内存资源：每个 MySQL 连接会占用一定内存（约 200KB~ 几 MB，取决于查询复杂度），过多连接会耗尽服务器内存。
文件描述符：MySQL 每个连接对应一个文件描述符，操作系统对进程的文件描述符有上限（如 ulimit -n 通常默认 1024）。
性能瓶颈：过多连接会导致 MySQL 线程上下文切换频繁，CPU 负载飙升，反而降低性能。

默认值与有效上限

默认 max_connections 为 151（MySQL 5.7+），最小为 1，理论最大可设为 100000（但受系统限制）。
实际有效上限：通常建议不超过 500~1000（除非服务器内存充足且连接均为短连接）。

连接数过多的常见原因

解决 “too many connections” 的核心是找到连接数激增的根源，而非单纯调大 max_connections。常见原因包括：

应用未正确释放连接

连接泄漏：应用使用连接后未调用 close() 释放（如 Java 未关闭 Connection，Python 未关闭 cursor），导致连接长期处于 Sleep 状态。
连接池配置不当：连接池的 maxPoolSize 设得过大（如超过 max_connections），或未设置 maxIdleTime 回收闲置连接。

慢查询 / 长事务阻塞连接

耗时过长的查询（如未加索引的全表扫描）或未提交的长事务，会导致连接长期处于 Running 或 Locked 状态，无法释放，新连接不断累积。

阅读全文 »

网络IO

发表于 2022-01-23 更新于 2025-08-11 分类于 java基础阅读次数： Valine：
本文字数： 8.1k 阅读时长 ≈ 7 分钟

Java 网络 IO 模型详解：从 Linux 内核到实践

网络 IO 是分布式系统的核心基础，其性能直接影响程序的并发能力和响应速度。本文从 Linux 内核的 5 种网络 IO 模型出发，解析 Java 中 BIO、NIO 等模型的实现原理、优缺点及适用场景，帮助理解高并发网络编程的底层逻辑。

Linux 网络 IO 模型：5 种核心模式

网络 IO 的本质是 “数据从外部设备（如网卡）传输到用户进程缓冲区” 的过程，涉及两个关键阶段：

数据准备阶段：数据从设备复制到内核缓冲区（Kernel Buffer）。
数据复制阶段：数据从内核缓冲区复制到用户进程缓冲区（User Buffer）。

根据这两个阶段的 “等待方式” 不同，Linux 定义了 5 种 IO 模型：

阻塞 IO 模型（Blocking IO）

核心特点：进程发起 IO 操作后，会一直阻塞（挂起），直到两个阶段完成（数据准备 + 复制到用户缓冲区）才唤醒。
流程：
- 用户进程调用 recvfrom 系统调用，内核开始数据准备。
- 数据未准备好时，进程进入阻塞状态（释放 CPU）。
- 数据准备完成后，内核将数据从内核缓冲区复制到用户缓冲区，然后唤醒进程，recvfrom 返回。
优缺点：实现简单，但进程阻塞期间无法处理其他任务，并发能力极差。

非阻塞 IO 模型（Non-Blocking IO）

核心特点：进程发起 IO 操作后不阻塞，若数据未准备好，立即返回错误（如 EWOULDBLOCK）；进程需定期轮询检查数据是否就绪。
流程：
- 用户进程调用 recvfrom，若数据未准备好，内核立即返回错误（非阻塞）。
- 进程不断轮询调用 recvfrom，直到数据准备好。
- 数据准备完成后，内核将数据复制到用户缓冲区，recvfrom 返回成功。
优缺点：进程无需阻塞，但轮询会消耗 CPU 资源，效率较低。

IO 复用模型（IO Multiplexing）

核心特点：通过 select/poll/epoll 等系统调用，单个进程可同时监控多个文件描述符（FD）的 IO 事件，阻塞等待任一事件就绪后再处理。
流程：
- 进程调用 select，传入需监控的 FD 集合，阻塞等待。
- 内核监控这些 FD，当任一 FD 数据就绪（或超时），select 返回就绪的 FD 数量。
- 进程遍历就绪的 FD，调用 recvfrom 完成数据复制。
关键改进：
- select/poll：采用轮询方式检查 FD 状态，支持的 FD 数量有限（select 通常为 1024）。
- epoll（Linux 2.6+）：基于事件驱动，通过回调函数通知就绪 FD，无 FD 数量限制，性能远超 select/poll。
优缺点：单进程管理多 FD，减少线程开销，适合高并发；但仍需主动调用 recvfrom 完成数据复制（同步模型）。

信号驱动 IO 模型（Signal-Driven IO）

核心特点：进程通过 sigaction 注册信号处理函数，内核数据准备好后发送 SIGIO 信号通知进程，进程再调用 recvfrom 复制数据。
流程：
- 进程调用 sigaction 注册信号处理函数（非阻塞，立即返回）。
- 数据准备好时，内核发送 SIGIO 信号，触发处理函数。
- 处理函数中调用 recvfrom，将数据从内核缓冲区复制到用户缓冲区。
优缺点：数据准备阶段非阻塞，但数据复制阶段仍需进程主动处理，适用场景有限（如 UDP 协议）。

异步 IO 模型（Asynchronous IO）

阅读全文 »

Shell 重定向与管道：数据流转的核心工具

重定向：控制命令的输入与输出

输出重定向：> 与 >>

（1）覆盖输出 >

（2）追加输出 >>

MySQL 查询状态详解：通过 show full processlist 解析线程行为

查询状态的查看方式

常见查询状态及含义

1. Sleep

责任链模式（Chain of Responsibility Pattern）：请求的链式传递与处理

责任链模式的核心结构

抽象处理器（Handler）

具体处理器（ConcreteHandler）

代码实现示例

1. 抽象处理器与请求类

2. 具体处理器（各级审批者）

3. 客户端使用（构建责任链并处理请求）

输出结果

责任链模式的核心优势

适用场景

优缺点分析

优点

缺点

经典应用案例

总结

MySQL 连接数问题深度解析：从错误原因到根治方案

“too many connections” 错误原理

连接数上限的限制因素

默认值与有效上限

连接数过多的常见原因

应用未正确释放连接

慢查询 / 长事务阻塞连接

Java 网络 IO 模型详解：从 Linux 内核到实践

Linux 网络 IO 模型：5 种核心模式

阻塞 IO 模型（Blocking IO）

非阻塞 IO 模型（Non-Blocking IO）

IO 复用模型（IO Multiplexing）

信号驱动 IO 模型（Signal-Driven IO）

异步 IO 模型（Asynchronous IO）

输出重定向：`>` 与 `>>`

（1）覆盖输出 `>`

（2）追加输出 `>>`

MySQL 查询状态详解：通过 `show full processlist` 解析线程行为