企业官网建设流程全解析

一、问题分类与排查思路

1.性能问题

• 表现：响应慢、CPU/内存使用率高、吞吐量下降

• 排查路径：

  1. 监控指标定位（CPU、内存、线程数、GC次数）

  2. 线程栈分析（jstack）

  3. 性能分析工具（Arthas、JProfiler）

2.稳定性问题

• 表现：服务宕机、OOM、频繁Full GC

• 排查路径：

  1. 日志分析（应用日志、GC日志）

  2. 堆转储分析（jmap、MAT）

  3. 依赖检查（数据库、Redis、MQ等）

3.数据问题

• 表现：数据不一致、脏数据、事务问题

• 排查路径：

  1. 数据追踪（业务日志、binlog）

  2. 事务分析（数据库锁、事务隔离级别）

  3. 代码逻辑审查

二、排查工具箱

基础工具

# 进程查看 jps -l ps -ef | grep java # 线程分析 jstack <pid> > thread.dump top -Hp <pid> # 查看线程CPU占用 # 内存分析 jmap -heap <pid> jmap -dump:live,format=b,file=heap.bin <pid> jstat -gcutil <pid> 1000 10 # GC统计 # 网络分析 netstat -antp | grep <port> ss -s # socket统计

高级诊断工具

1. Arthas- 阿里巴巴开源诊断工具

# 安装启动 curl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar # 常用命令 dashboard # 整体监控 thread # 查看线程 watch # 方法观测 trace # 方法调用链追踪 jad # 反编译类

1. JProfiler/VisualVM- 图形化分析

2. Prometheus + Grafana- 监控告警

三、系统化排查流程

第一步：现象收集

# 1. 系统资源 top -c free -h df -h iostat -x 1 # 2. JVM信息 jinfo <pid> jcmd <pid> VM.flags # 3. 应用日志 tail -n 1000 app.log | grep ERROR tail -f app.log | grep -A 10 -B 5 "关键词"

第二步：定位问题类型

# CPU高问题 # 1. 找到高CPU进程 top -c # 2. 找到高CPU线程（将PID转为16进制） top -Hp <pid> printf "%x\n" <tid> # 3. 分析线程栈 jstack <pid> | grep -A 10 <nid_hex> # 内存问题 # 1. 实时监控 jstat -gc <pid> 1000 # 2. 生成堆转储 jmap -dump:live,format=b,file=heap.hprof <pid> # 或使用jcmd（推荐） jcmd <pid> GC.heap_dump /tmp/heap.hprof

第三步：深入分析

线程死锁排查

// 使用Arthas快速诊断 thread -b // 查找阻塞线程 thread --state BLOCKED // 查看阻塞状态线程 // 或使用jstack jstack <pid> | grep -A 20 "deadlock"

内存泄漏排查

# 1. 分析堆转储 # 使用Eclipse Memory Analyzer (MAT) # 或jhat jhat heap.hprof # 访问 http://localhost:7000 # 2. 查看对象直方图 jmap -histo:live <pid> | head -20

慢SQL排查

-- 开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2; -- 查看当前慢查询 SHOW PROCESSLIST; SHOW FULL PROCESSLIST; -- 使用EXPLAIN分析执行计划 EXPLAIN SELECT * FROM table WHERE ...

四、常见问题场景及解决方案

场景1：CPU使用率100%

排查步骤：

1. top -c找到高CPU Java进程

2. top -Hp <pid>找到高CPU线程

3. jstack <pid> > thread.txt

4. 线程ID转16进制：printf "%x\n" <tid>

5. 在thread.txt中搜索对应线程

6. 分析代码逻辑（常见：死循环、大量计算、频繁GC）

场景2：内存泄漏OOM

排查步骤：

# 1. 添加JVM参数（提前预防） -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log # 2. 分析堆转储 # 使用MAT打开heap dump，查看： # - Dominator Tree（支配树） # - Leak Suspects（泄漏疑点） # - Histogram（对象直方图）

场景3：频繁Full GC

现象：应用卡顿、响应时间长

# 分析GC日志 jstat -gcutil <pid> 1000 10 # 常见原因： # 1. 年轻代太小：-Xmn调整 # 2. 内存泄漏：分析堆转储 # 3. 大对象：检查代码中的大数组、大集合 # 4. System.gc()调用：禁止-XX:+DisableExplicitGC

场景4：数据库连接池耗尽

// 监控连接池使用情况 // HikariCP HikariPoolMXBean pool = hikariDataSource.getHikariPoolMXBean(); System.out.println("Active: " + pool.getActiveConnections()); System.out.println("Idle: " + pool.getIdleConnections()); System.out.println("Total: " + pool.getTotalConnections()); // 排查方向： // 1. 慢SQL导致连接持有时间过长 // 2. 事务未及时提交 // 3. 连接泄漏（未关闭ResultSet/Statement/Connection）

五、进阶排查技巧

1.使用Arthas进行动态诊断

# 监控方法调用 watch com.example.service.*Service * '{params,returnObj,throwExp}' -x 3 # 追踪调用链 trace com.example.service.*Service * -j # 热更新代码（紧急修复） jad --source-only com.example.ProblemClass > /tmp/ProblemClass.java # 修改代码后 mc /tmp/ProblemClass.java -d /tmp redefine /tmp/com/example/ProblemClass.class

2.网络问题排查

# 连接数统计 netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c # 端口检查 nc -zv host port telnet host port # 抓包分析（谨慎使用） tcpdump -i any port 8080 -w capture.pcap

3.分布式链路追踪

// 集成SkyWalking、Zipkin等 // 查看完整调用链路，定位慢在哪一环

六、预防与最佳实践

1.监控体系建设

• 应用指标：QPS、RT、错误率

• JVM指标：GC次数、堆内存、线程数

• 系统指标：CPU、内存、磁盘、网络

• 业务指标：关键业务流程监控

2.日志规范

// 结构化日志 logger.info("order_created", StructuredLog.create() .with("orderId", orderId) .with("amount", amount) .with("userId", userId) .with("costTime", costTime)); // 关键位置添加TraceID MDC.put("traceId", traceId);

3.代码层面防护

// 超时控制 @Bean public RestTemplate restTemplate() { return new RestTemplateBuilder() .setConnectTimeout(Duration.ofSeconds(5)) .setReadTimeout(Duration.ofSeconds(10)) .build(); } // 熔断降级 @HystrixCommand(fallbackMethod = "fallbackMethod") public String riskyOperation() { // ... } // 限流 RateLimiter limiter = RateLimiter.create(100); // 100QPS

4.应急预案

1. 快速回滚脚本

2. 服务降级开关

3. 流量切分能力

4. 线上诊断工具预装

七、总结

生产问题排查的核心思路：

1. 先恢复，后定位：优先保障服务可用性

2. 从外到内：网络 → 系统 → 应用 → 代码

3. 工具熟练：掌握至少一种深度诊断工具

4. 数据驱动：基于监控数据和日志分析

5. 持续优化：将排查经验转化为监控告警和代码规范