Java服务器死机与启动问题全解析：从诊断到恢复

一、Java服务器死机的常见原因与诊断方法

1.1 内存溢出（OOM）导致的死机

原因分析：Java应用因内存泄漏或配置不当导致堆内存耗尽，触发OutOfMemoryError，系统进入假死状态。常见场景包括未关闭的数据库连接、缓存无限增长、大对象未及时释放等。

诊断步骤：

1. 查看日志：检查应用日志（如catalina.out或logs/system.log）中是否存在java.lang.OutOfMemoryError错误。
2. 内存分析工具：使用jmap导出堆内存快照（jmap -dump:format=b,file=heap.hprof <pid>），通过MAT（Eclipse Memory Analyzer）分析内存泄漏点。
3. 监控指标：通过jstat -gcutil <pid> 1000监控GC频率与内存使用率，若老年代（Old Gen）持续接近100%且Full GC频繁，则可能存在内存问题。

解决方案：

• 调整JVM参数：增大堆内存（-Xms512m -Xmx2g），优化新生代与老年代比例（-XX:NewRatio=2）。
• 代码优化：使用WeakReference管理缓存，及时关闭InputStream、ResultSet等资源。
• 升级依赖：检查第三方库（如Hibernate、Spring）是否存在已知内存泄漏问题。

1.2 线程阻塞与死锁

原因分析：多线程环境下，线程因同步锁（synchronized）竞争或I/O操作阻塞导致服务不可用。例如，数据库连接池耗尽时，线程等待连接超时。

诊断步骤：

1. 线程转储：执行jstack <pid> > thread_dump.log，分析线程状态（BLOCKED、WAITING）。
2. 死锁检测：在日志中搜索deadlock关键字，或使用jconsole的“死锁检测”功能。
3. 连接池监控：检查连接池（如HikariCP、Druid）的activeConnections和idleConnections，若activeConnections接近最大值且线程堆积，则可能为连接泄漏。

解决方案：

• 优化锁策略：减少synchronized块范围，改用ReentrantLock或ConcurrentHashMap。
• 连接池配置：调整最大连接数（maximumPoolSize），设置合理的超时时间（connectionTimeout）。
• 异步处理：将耗时操作（如文件上传、外部API调用）改为异步任务（如CompletableFuture）。

1.3 系统资源耗尽

原因分析：CPU 100%、磁盘I/O饱和或文件描述符不足导致服务无响应。例如，频繁的全表扫描导致数据库CPU过高，进而影响Java应用。

诊断步骤：

1. 系统监控：使用top（Linux）或任务管理器（Windows）查看CPU、内存使用率。
2. I/O分析：通过iotop（Linux）或Resource Monitor（Windows）定位高I/O进程。
3. 文件描述符：执行ls -l /proc/<pid>/fd | wc -l检查文件描述符数量，若接近系统限制（ulimit -n），则可能因未关闭文件或网络连接导致泄漏。

解决方案：

• 资源扩容：升级服务器配置（CPU、磁盘SSD）。
• 代码优化：减少磁盘写入（如合并日志输出），使用批量操作替代单条SQL。
• 系统调优：调整Linux文件描述符限制（/etc/security/limits.conf中设置nofile=65535）。

二、Java服务启动失败的常见场景与修复

2.1 端口冲突

现象：启动时报错Address already in use，通常因其他进程占用了应用配置的端口（如8080）。

解决方案：

1. 查找占用进程：

   # Linux
   netstat -tulnp | grep 8080
   # 或
   lsof -i :8080
   # Windows
   netstat -ano | findstr 8080

2. 终止进程：根据PID执行kill -9 <pid>（Linux）或taskkill /PID <pid> /F（Windows）。
3. 修改端口：在application.properties中更改端口（server.port=8081），或通过启动参数指定（-Dserver.port=8081）。

2.2 类加载失败

现象：启动时报错ClassNotFoundException或NoClassDefFoundError，通常因依赖缺失或版本冲突。

解决方案：

1. 检查依赖：
   • 使用mvn dependency:tree（Maven）或gradle dependencies（Gradle）分析依赖树。
   • 排除冲突版本（如<exclusions><exclusion><groupId>com.conflict</groupId><artifactId>lib</artifactId></exclusion></exclusions>）。
2. 清理缓存：删除~/.m2/repository（Maven）或~/.gradle/caches（Gradle）下的相关目录，重新下载依赖。
3. 模块化部署：将应用打包为Fat JAR（使用spring-boot-maven-plugin的repackage目标），确保所有依赖包含在内。

2.3 数据库连接失败

现象：启动时报错Unable to acquire JDBC Connection，通常因数据库服务未启动、URL配置错误或权限不足。

解决方案：

1. 验证数据库服务：
   • 检查数据库进程是否运行（如systemctl status mysql）。
   • 尝试手动连接（如mysql -u root -p）。
2. 检查配置：
   • 确认spring.datasource.url、username、password正确。
   • 测试连接字符串（如jdbc//localhost:3306/db?useSSL=false）。
3. 权限调整：为数据库用户授予足够权限（如GRANT ALL PRIVILEGES ON db.* TO 'user'@'%';）。

三、预防与优化建议

3.1 监控与告警

• 实时监控：部署Prometheus+Grafana监控JVM指标（内存、GC次数）、系统资源（CPU、磁盘I/O）。
• 日志告警：通过ELK（Elasticsearch+Logstash+Kibana）或Fluentd收集日志，设置关键错误告警（如OutOfMemoryError）。

3.2 自动化部署

• 容器化：使用Docker封装Java应用，通过docker-compose管理依赖服务（如MySQL、Redis）。
• CI/CD流水线：集成Jenkins或GitLab CI，实现代码提交后自动构建、测试与部署。

3.3 灾备方案

• 蓝绿部署：准备两套环境（蓝/绿），通过负载均衡器切换流量，降低停机风险。
• 滚动更新：在Kubernetes中采用RollingUpdate策略，逐步替换Pod，确保服务连续性。

结语

Java服务器死机与启动问题涉及内存、线程、系统资源等多方面，需结合日志分析、工具监控与代码优化综合解决。通过预防性措施（如监控告警、自动化部署）可显著降低故障率，保障业务稳定性。开发者应熟练掌握jstack、jmap等工具，并建立系统的故障排查流程，以快速响应生产环境问题。