bindexception 是操作系统报出的端口占用异常，表明 jvm 尝试绑定的端口（如 8080）已被其他进程占用；常见于 spring boot 启动卡在 web 服务器初始化阶段，需用 lsof、netstat 或 netstat -ano 定位并终止冲突进程，或通过配置 server.port、vm 参数、docker 端口映射等避免重复绑定。
BindException 是什么，为什么它总在启动时炸出来
Java 程序抛 BindException: Address already in use，基本等于操作系统说：“这端口我刚分给另一个进程了，你别抢”。它不是 Java 自己的逻辑错，而是底层 socket 绑定失败——JVM 想监听 8080，但系统发现 8080 已被某个进程（可能是残留的旧服务、IDE 内嵌服务器、甚至 Docker 容器）占着。
常见错误现象：
- Spring Boot 启动卡在 “Starting Servlet Web Server” 后直接报错
- Tomcat 或 Jetty 启动日志里出现
java.net.BindException: Address already in use - 同一台机器上改了端口重试就 OK，说明纯属端口冲突
怎么快速定位哪个进程占了端口（Linux/macOS/Windows 都得会）
别急着杀进程，先确认是谁在用。不同系统命令略有差异，但目标一致：查出 PID。
Linux/macOS：
立即学习“Java免费学习笔记（深入）”；
-
lsof -i :8080—— 最直接，显示占用8080的进程名和 PID -
netstat -tulpn | grep :8080—— 有些老系统没lsof，就用这个
Windows：
-
netstat -ano | findstr :8080—— 注意末尾是 PID，记下来 - 再开任务管理器 → “详细信息” 页，找对应 PID 的进程，右键“结束任务”
⚠️ 容易踩的坑：别只查 localhost:8080，有些服务绑定的是 0.0.0.0:8080 或 [::]:8080（IPv6），lsof -i :8080 能覆盖全部；而 netstat -an | grep 8080 可能漏掉监听状态为 LISTEN 但未建立连接的条目。
临时绕过：换端口最安全，但要注意配置层级
开发阶段换端口最快，但必须搞清配置生效位置，否则改了白改。
- Spring Boot：优先改
application.properties里的server.port=8081；如果用了@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)，那测试时自动随机，不走这个配置 - Tomcat 嵌入式：Spring Boot 下它由
server.port控制；独立 Tomcat 则改$CATALINA_HOME/conf/server.xml中Connector port="8080" - Java 原生
ServerSocket：检查代码里是不是硬编码了new ServerSocket(8080)—— 这种必须改源码
⚠️ 性能影响：端口本身无性能差别，但若盲目改成 1024 以下（如 80），Linux/macOS 需要 root 权限，反而导致启动失败；Windows 对低编号端口限制少些，但仍建议避开 0–1023。
彻底解决：避免下次再撞上（尤其 CI/CD 和本地多项目并行）
端口冲突本质是资源管理混乱。单机开发常同时跑多个 Spring Boot 项目，每个默认都盯 8080，不设防早晚撞车。
- 开发时统一加 profile：比如
application-dev.yml里写server.port: ${PORT:8080}，启动时传--PORT=8081，比硬编码灵活 - IDE 启动配置里加 VM options：
-Dserver.port=8082，这样同一个项目多次 Run 不会互相干扰 - Docker 场景：检查
docker-compose.yml是否重复映射了宿主机端口，比如两个 service 都写了"8080:8080"，得改成"8081:8080"和"8082:8080"
容易被忽略的一点：某些 IDE（如 IntelliJ）的“Run Configuration”里勾了 “Allow parallel run”，看似方便，实则让多个实例争抢同一端口——这种情况下，哪怕改了配置，只要没关掉这个选项，照样崩。
