1、项目经历

暴露问题：亮点、难点不够突出

表述方式：项目内容，负责模块，关键难点，我的亮点，最终结果数据、与其他人对比）

项目选择：

1）突出技术难点

2）突出业务亮点

2、技术问题

2-1 线上问题排查工具-heapdump

在故障定位和性能分析的时候，经常会用到一些文件辅助排除代码问题。heap dump 记录了内存信息，可以用于内存溢出等问题的排查。具体的使用方式，可参考JVM heap dump分析。

2-2 top 命令

top 命令查看 cpu 最高的进程，然后怎么查看各线程情况

top 命令，交互命令 - H，查看每个线程的性能信息 top -Hp pid

其他操作： P-按照 CPU 排序，M-按照内存排序

2-3 hbase

在项目中怎样使用的，hbase 的最大特点，hive 怎么使用的，包含哪些统计指标

2-4 使用 aop 实现日志采集

AOP 代码修改的两个时机：

1.在编译 java 源代码的时候 ----编译时增强

2.在运行时动态地修改类 ----运行时增强（动态代理）

实现：

1、定义切面 @interface LogServiceAspect 注解

切入点表达式 标识拦截哪些方法

2、定义拦截器

判断是否有注解，加入切面业务逻辑：拦截器 TestInterceptor 统一切面日志 参数校验、统一异常处理、日志打印 @Pointcut(value = "@annotation(logServiceAspect)")

2-5 如何定位问题到代码 - cpu 和 内存

1、通过 top 命令查看占用 cpu 比较高的进程 id。 ps 查看进程信息

2、top -Hp pid，查看进程下哪些线程有问题

3、线程 id（数字，类似 164069） 转成 16 进制。转换之后分别是 280e5，280e6，280e7，280e8

4、转成 16 进制以后，再通过 jstack threadId 查看具体的线程信息，nid 匹配， 例如定位到时 gc 线程(GC task thread#0 标记)

5、jmap -heap 164065 看一下堆内存吧。新生代的空间已经用了 100%，老年代的空间的使用也达到了 99.87%。看到这里，估计大家都明白了。为啥 GC 线程会不停的占用 cpu。原来是堆内存的新生代和老年代的空间不够了，需要进行 fullGC 和 minorGC，但是每次 fullGC 和 monorGC 只能释放一点点空间，然后很快又达到了需要 GC 的程度。再进行 GC，如此循环导致 GC 的线程疯狂调用。必须要强调的是，这里正好达到了即将发生 OOM，但是还没有发生 OOM，立马进行 GC 这么一个平衡。所以 GC 线程才能如此嚣张的占用 CPU.

capacity 总容量， used 已用

6、jstat -GC pid，查看一下 GC 的频率

7、继续分析，为什么堆内存会不够用呢：

分析 dump。通过 jmap -dump:format=b,file=taskDump.bin 生产 dump 文件，然后通过 jhat/zprofiler 对堆内存进行分析

这个 dump 文件里面有三个对象非常大，加在一起基本上有 300M。而我们这个进程的 jvm 堆内存配置的最大才 512M。这三个大对象都是 forest 包里面的，再联想到两周前才做过 viewcache 到 forest 的迁移，这两周开始出现的 cpu 利用率飙高的谜题终于真相大白了。

解决办法很简单，加大 JVM 的堆内存配置大小。同时通知一下 forest 那边的团队，你们的常驻堆内存的对象太大了，要不要进行优化一下。

3、系统设计

3-1 运维系统设计

设计时包含哪些子系统/模块，之间如何交互

我的回答：采集、接收、存储； 报警；扩容；安全