小菜鸟

优化 IntelliJ IDEA 项目构建速度：解决 Build 缓慢与 GC 问题

IntelliJ IDEA 作为主流的 Java 开发工具，在处理大型项目时常常遇到构建（Build）缓慢甚至触发 GC（垃圾回收）的问题。仅仅调整 IDE 内存配置往往无法彻底解决，需要结合编译参数、自动编译策略等多方面优化。本文将详细介绍针对性的解决方案。

核心问题分析

大型项目构建缓慢或触发 GC 的常见原因：

1. 编译堆内存不足：IDEA 编译模块默认堆内存较小（700M），无法满足大型项目需求，导致频繁 GC。
2. IDE 内存配置不合理：JVM 堆内存（Xms/Xmx）设置过小，影响 IDE 整体性能。
3. 增量编译未生效：每次构建都执行全量编译，重复处理未修改的代码。
4. 不必要的编译任务：如自动编译触发时机不当，或开启了不必要的编译检查。

分步优化方案

1. 调整 IDE 自身 JVM 内存配置

虽然单独调整内存无法彻底解决编译问题，但合理的配置是基础：

• 配置文件位置：

  • Windows：C:\Program Files\JetBrains\IntelliJ IDEA xxxx.x\bin\idea64.exe.vmoptions
  • Mac：/Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions
  • 也可通过 IDE 菜单打开：Help → Edit Custom VM Options

• 推荐配置（根据内存调整）：

  1 2 3 4 5

  -Xms1024m # 初始堆内存（建议设为物理内存的 1/8） -Xmx4096m # 最大堆内存（建议设为物理内存的 1/4，如 16G 内存可设为 4096m） -XX:ReservedCodeCacheSize=1024m # 代码缓存（大型项目建议 1024m） -XX:+UseG1GC # 使用 G1 收集器，减少 GC 停顿 -XX:MaxGCPauseMillis=200 # 目标 GC 停顿时间（毫秒）

• 生效方式：修改后重启 IDE。

2. 增大编译模块堆内存（关键优化）

IDEA 的编译模块（javac）有独立的堆内存限制，默认 700M，大型项目需手动调大：

1. 打开配置页面：File → Settings → Build, Execution, Deployment → Compiler。
2. 找到 Build process heap size (Mbytes)，默认值为 700。
3. 根据项目大小调整：
   • 中型项目：1500-2000M
   • 大型项目：2000-4000M（如设置为 2048M）。
4. 点击 Apply 保存。

本地开发效率提升：将 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筛选目标端口，语法如下：

   1	netstat -ano | findstr "端口号"

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

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

   1	netstat -ano | findstr "8990"

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

   1	TCP 127.0.0.1:8990 0.0.0.0:0 LISTENING 2700

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

根据进程 ID 查询进程名称

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

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 解码：

1
2
3
4

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

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

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

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