小菜鸟

本地开发效率提升：将 Consul 设置为 Windows 开机自启的完整方案

在微服务开发中，Consul 作为服务注册中心是很多项目的基础依赖。但每次启动项目前手动启动 Consul，不仅繁琐还容易遗忘，经常导致服务启动失败。本文分享一种简单可靠的方案，通过 Windows 开机自启功能自动启动 Consul，彻底解决这个痛点。

基础方案：利用系统启动目录实现自启

Windows 系统提供了便捷的开机启动机制，只需将程序或脚本放入特定目录，即可实现开机自动运行。这种方式无需复杂配置，适合快速上手。

步骤 1：准备文件

• 将 Consul 的可执行文件（consul.exe）复制到本地目录（建议路径不含中文和空格，如 C:\Tools\Consul）。
• 新建一个启动脚本（start_consul.bat），用于自动化启动流程。

步骤 2：编写启动脚本

脚本的核心作用是切换到 Consul 所在目录，检查文件完整性，并启动服务。优化后的脚本如下：

ZooKeeper 核心原理与实践解析

ZooKeeper 作为分布式系统中的 “协调者”，在解决集群协同问题上扮演着关键角色。以下从核心原理、工作机制和典型应用场景展开说明，帮助深入理解其设计与价值。

为什么需要zookeeper

对于多线程的弊端，看下图

Windows 中查看端口占用并结束进程的方法

在开发或运维过程中，经常会遇到 “端口被占用” 的问题（如启动服务时提示 “Address already in use”）。以下是通过 CMD 命令行快速定位端口占用进程并结束它的完整步骤：

查看指定端口被哪个进程占用

1. 打开 CMD 命令行：
   按下Win + R，输入cmd，回车打开命令提示符（无需管理员权限）。

2. 执行端口查询命令：
   使用netstat命令结合findstr筛选目标端口，语法如下：

   netstat -ano | findstr "端口号"

   • netstat -ano：列出所有网络连接（-a）、显示端口号（-n）、显示进程 ID（-o）。
   • findstr "端口号"：从结果中筛选包含目标端口的记录。

   示例：查询 8990 端口的占用情况

   netstat -ano | findstr "8990"

3. 解析结果：
   输出格式为：协议 本地地址:端口 外部地址 状态 进程ID(PID)
   例如：

   TCP    127.0.0.1:8990         0.0.0.0:0              LISTENING       2700

   说明：8990 端口被进程 ID 为 2700的程序占用，状态为 “LISTENING”（监听中）。

根据进程 ID 查询进程名称

通过第一步获取的进程 ID（PID），可以进一步找到对应的程序名称：

单元测试中数据库数据未更新的问题解析：自动回滚机制与解决方案

在进行单元测试（尤其是涉及数据库操作的测试）时，常遇到 “测试执行成功但数据库数据未变化” 的现象。这通常与测试框架的事务自动回滚机制有关，本文将解析其原理并提供解决方案。

问题根源：测试框架的自动回滚机制

主流的 Java 测试框架（如 Spring Test）为了避免测试数据污染数据库，默认会对测试方法中的数据库操作进行自动回滚。其核心逻辑是：

1. 测试方法执行前，框架开启一个事务；
2. 测试方法中的数据库操作（如插入、更新）在该事务中执行；
3. 测试方法执行成功后，框架自动回滚事务，所有操作不提交到数据库；
4. 若测试失败，同样会回滚事务，保证数据库状态不受影响。

这一机制的优点是隔离测试数据，避免多次测试之间的相互干扰，但也会导致 “测试成功却看不到数据变化” 的现象。

解决方案：禁用自动回滚

若需要在测试后保留数据库数据（如验证数据正确性、调试测试逻辑），可通过以下方式禁用自动回滚：

使用 @Rollback 注解（Spring Test）

在测试方法或测试类上添加 @Rollback(false)，显式关闭自动回滚：

import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.junit4.SpringRunner;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.transaction.annotation.Transactional;

@RunWith(SpringRunner.class)
@Transactional // 开启事务（默认会回滚）
public class UserDaoTest {

    @Test
    @Rollback(false) // 禁用自动回滚，测试完成后提交事务
    public void testInsertUser() {
        // 数据库插入操作（如 userDao.insert(new User("test"))）
        // 测试成功后，数据会保留在数据库中
    }
}

Java Web 中文乱码问题全解析：GET/POST 请求编码解决方案

中文乱码是 Java Web 开发中常见的问题，根源在于请求参数编码与解码方式不匹配。GET 和 POST 请求的参数传递方式不同，乱码原因和解决方案也存在差异。本文将详细分析中文乱码的成因，并提供针对性的解决方法，覆盖 Tomcat 配置、代码处理等多种场景。

中文乱码的本质原因

HTTP 协议默认使用 ISO-8859-1 编码（不支持中文），若客户端发送的中文参数使用 UTF-8 编码，而服务器端用 ISO-8859-1 解码，就会导致乱码（表现为 ??? 或一串无意义字符）。

• GET 请求：参数附加在 URL 中，编码由服务器的 URI 编码配置决定；
• POST 请求：参数放在请求体中，编码由 Content-Type 头的 charset 指定，若未指定则默认使用 ISO-8859-1。

GET 请求中文乱码解决方案

GET 请求参数通过 URL 传递，其编码处理依赖服务器配置（如 Tomcat 的 URI 编码设置），常见解决方案如下：

方案一：修改 Tomcat 配置（推荐）

在 Tomcat 的 conf/server.xml 中，为 Connector 节点添加 URIEncoding="UTF-8" 属性，强制服务器对 URI 中的参数使用 UTF-8 解码：

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           URIEncoding="UTF-8" /> <!-- 添加此行 -->

• 作用：所有 GET 请求的 URL 参数均使用 UTF-8 解码，一劳永逸解决乱码；
• 适用场景：有权限修改服务器配置的环境（如开发、测试环境）。

方案二：使用请求体编码同步 URI 编码

若无法修改 Tomcat 配置，可在 Connector 中添加 useBodyEncodingForURI="true"，使 URI 编码与请求体编码保持一致：