端口被占用的本质是某个进程已经抢先绑定在了这个端口上，你要么把那个进程找出来处理掉，要么让当前应用换个端口，两条路都能快速解决问题。
端口冲突到底是怎么发生的
先把概念说清楚,服务器里的每一个端口就像一扇带锁的门，操作系统规定同一时间只能有一个进程绑定在某个端口上听消息，当你的应用启动时，系统发现那扇门已经被人从里面锁死了，就会直接抛出一句类似Address already in use的错误。
端口冲突的常见来源
实际开发中,端口被占用多见于以下几种场景：
- 开发环境反复启动应用：上一次运行的项目没有彻底关闭，进程残留在后台，把端口死死攥住。
- 多实例部署忘改配置：两台服务或两个模块共用同一个端口号，后启动的一方必然报错。
- 系统服务悄悄占了端口：比如Windows的IIS、SQL Server，Linux的httpd、nginx，它们默认监听的端口可能与你的应用撞车。
- 被异常进程或恶意程序占用：某些挖矿木马、后门程序也会绑定端口，排查时容易让人摸不着头脑。
每个端口背后都有一个进程
这句话值得牢记：端口本身不会自己阻塞，阻塞它的一定是某个PID对应的进程。 所以处理端口冲突的思路永远只有三步，找出占用进程，确认它是否该被清理，然后决定是杀掉它还是改自己的端口，行业共识认为，多数端口冲突都发生在开发调试阶段，真正因为生产环境配置不当导致的占比较小。
如何确认8080端口被占用
动手解决之前,先得搞清楚是谁占了端口，不同操作系统有不同的命令，但思路完全一致。
Windows下查看端口占用命令
打开命令提示符（cmd）或PowerShell，输入：
netstat -ano | findstr 8080
这条命令会列出所有包含8080字样的TCP连接，以及它们各自的进程PID，举个例子，输出结果末尾的12345就是一个PID，紧接着输入：
tasklist | findstr 12345
这条命令会告诉你PID对应的程序名,比如
java.exe、python.exe或nginx.exe，确认无误后，果断执行：
taskkill /F /PID 12345
/F表示强制结束，/PID指定进程号，如果你不想用命令操作，也可以打开任务管理器，切到“详细信息”标签页，按PID排序找到对应进程，右键结束任务。
Linux下查看端口占用命令
Linux下最顺手的是ss命令，它比老的netstat更快更全面，输入：
ss -tlnp | grep 8080
-t只看TCP，-l只显示监听中的端口，-n以数字形式显示端口号，-p显示进程信息，输出中你会看到类似pid=4567的字段，或者用很多人习惯的lsof：
lsof -i:8080
它会直接列出占用该端口的进程名和PID,确认后执行：
kill -9 4567
如果你没有权限杀掉别人的进程,考虑用sudo提权，还有一种情况需要注意：进程明明被杀，端口却依然被占用，这多半是因为端口还处于TIME_WAIT状态，等一两分钟让系统自动回收即可，业内专家指出，在连接密集的服务器上，TIME_WAIT状态的端口积压是比较常见的一种假性占用。
端口被占用怎么排查：先判断再动手
很多人一看到端口占用就直接kill -9，这其实有风险，假如你杀掉的是数据库或者负载均衡的核心进程，影响的就不止一个应用了，所以动手之前，花半分钟做一次排查。
看进程路径，判断身份
Windows下用wmic process where processid=4567 get executablepath，Linux下用ls -l /proc/4567/cwd，这条路径能告诉你这个进程是从哪个目录、哪个程序启动的，如果路径指向你自己的项目目录，放心处理；如果指向系统目录或者奇怪的临时目录，要提高警惕。
查服务状态，排除系统组件
Windows下执行sc query查看服务列表，Linux下用systemctl status 4567或配合ps aux | grep 4567确认进程归属，很多Windows端口冲突其实来自
http.sys系统服务，它默认会抢占一部分端口范围。
翻应用日志，看框架明文提示
Spring Boot项目启动失败时，日志里会写明Port 8080 was already in use，Tomcat会提示lifecycleException，Nginx会告诉你bind() to 0.0.0.0:80 failed，日志里的信息通常比命令输出更直接，能帮你快速缩小排查范围。
端口被占用tomcat启动失败？试试这两种解决方案
排查完成之后,就到了真正动手解决的环节，以Tomcat为例，端口被占用时启动会直接失败，解决方案无非两条路。
结束占用进程，保留原端口
如果当前端口是业务约定好的（比如前端只允许访问8080，或者安全管理要求监听80），那就保住端口，把占用它的进程干掉，流程就是上文提到的：查PID，确认进程身份，结束它，重启你的Tomcat。
不过在正式环境里要额外注意：尽量别用kill -9这种强制手段，先试试kill PID，给进程一个机会处理完手头的活儿再退出，避免留下脏数据或者未同步的文件，如果等了几秒还没退出，再考虑强制结束。
修改应用端口，绕开冲突
如果端口本身不固定,或者你不想打扰已经正常运行的其他服务，那就给应用换个端口，Tomcat修改conf/server.xml里的Connector port="8081"即可，Spring Boot项目在application.yml里加一行server.port: 8081，Nginx则在配置文件的listen 8081;处调整。
换完端口后别忘了测试连通性,前端如果写死了后端接口地址，也要同步更新，如果你的服务部署在云服务器上，还要去控制台的安全组或防火墙规则里放行新端口，这一步漏掉的话，端口换了也照样连不上。
预防端口重复占用，从建表开始
解决过一次端口冲突之后,不妨想想怎么避免下次再犯，尤其在一台服务器上同时跑多个项目的场景下，端口规划比临场发挥重要得多。
建立端口使用清单
把每台服务器的端口、服务名、负责人、域名记录下来，不用做得多复杂，一个Excel表格就够，这个表的价值在于新项目上线前，可以先看一眼哪些端口是空闲的，避免跟已有服务撞车。
用固定端口范围隔离环境
开发环境用8080-8099，测试环境用9090-9099，生产环境按业务模块分段规划，不同环境之间的端口互不重叠，自然少了很多冲突，在本地开发时，还可以考虑让Spring Boot自动随机分配端口，用server.port=0启动，然后从日志里读取实际端口，但这种方式只适合临时联调，不适合对外的服务。
定期检查端口监听情况
运维同学可以写个简单的脚本,每隔一段时间跑一次ss -tlnp，把异常新增的监听端口记录下来，有了数据，遇到问题就能快速追溯到是哪个服务在什么时间点抢占的端口。
端口被占用常见问题解答
8080端口被占用能直接杀掉进程吗？
可以,但前提是你确认了那个进程不是数据库、中间件或别的线上服务，开发环境下，残留的Tomcat、Java进程直接杀掉没有副作用，不确定的话，先用tasklist或ps看一眼进程可执行路径，生产环境杀进程前最好先走变更流程，至少让运维同事知道你在做什么。
为什么杀完进程端口还在占用？
最常见的情况是端口处于TIME_WAIT状态，系统在等待旧连接上的残留数据包自然老化，这个状态一般持续几十秒到两分钟，其次是杀进程时没杀干净，进程有子进程还在运行，用ps -ef | grep 端口特征再查一次，把残留的子进程一并清理，还有一种极少见的情况是杀错了进程，真正占用端口的进程还活着。
服务器防火墙已经放行端口了，为什么外部还是访问不到？
先确认服务进程是否真的在监听这个端口,在服务器本机执行curl http://127.0.0.1:8080验证，本机能通而外部不通，问题多数出在云安全组规则没生效，或者端口监听在0.0.1而不是0:0.0.0.0，后者意味着服务只接收本机请求，对外完全不开放，把监听地址改成0.0.0并重启服务即可，端口冲突往往几分钟就能解决，但它背后暴露出来的是端口规划和进程管理的习惯问题，把排查命令记熟，再养成每次启动前看日志的习惯，这类问题基本不会在你手里卡住第二次。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/725335.html
