记一次线上问题排查经历 面试

背景

记得是今年3月份初的事情，我一个同事在之前写的一个程序receiver 。receiver主要是从第三方厂家接收数据，下载对应的图片，然后发给我们自己的产品。receiver跑了将近3个月都是正常的，没有任何问题。到三月份的时候，技术支持反馈数据断了，当时我们没有多大重视，只是让重启了，但是没过多久又断了 ，然后又让重启，没过10分钟就断了，然后接连很多次都是这样，当时我在忙别的项目，就没有一起排错。我们技术老大带着那个同事排查了一周，没有根本解决问题，然后他们自己在程序内部搞了一个定时器定时重启，来解决问题，但是定时重启又带了新的问题，因为receiver 程序是从Kafka 拉数据,重启程序的时候没有把偏移量提交了，然后导致消费重复的数据，使得数据延迟，并没有从根本上解决问题。最后又把定时重启去掉，然后正常跑起来一段时间了，最后那个同事离职了，最后那个该死的程序又断了，轮到我出场了。

receiver 程序构造

fetch data - 通过Kafka 客户端从Kafka 拉取数据，将Kafka里的数据映射为适配我们平台的数据格式，然后将数据放到一个给定长度的阻塞队列LinkedBlockingQueue中。
downloader-sender- 启动一个线程池,线程池中的任务就是从 上面的阻塞队列中取出数据,然后去根据数据里的url 去下载图片,最后组装成大json 发送给平台。

排查问题

日志排查

  线上问题一般情况下都是通过日志来定位的，所以日志是一定要打印，但是也不能胡乱打印。对warn 日志和error 日志我在这里多说一句：WARN表示可以恢复的问题，无需人工介入，ERROR表示需要人工介入问题。我们写程序之初，就应该想到如果这里出现问题，到了线上我怎么判定什么原因导致该问题，然后写到日志里指导运维人员去解决问题。因为大多数我们线上出现的问题都是由于环境问题导致的，这些运维人员是可以搞定的，我们只要明确的打印出是网络出了问题还是磁盘出了问题。
   为了后期排查问题我们前期设计了一个统计日志:接收数据的阻塞队列的size,上传成功的size,过滤掉的size。当时查看的日志如下面的场景：

2260467 [pool-4-thread-3] INFO  com.s.s.c.SE  – queue backlog size:1000;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE  – queue backlog size:100;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:965;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:300;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:480;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:560;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:356;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:102;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:923;consumed size:456231;consume success size:406223;filtered size:50,008;active thread size:12
2260467 [pool-4-thread-3] INFO  com.s.s.c.SE   – queue backlog size:482;consumed size:0456231;consume success size:406223;filtered size:50,008;active thread size:12

通过日志看出：阻塞队列里的数据不断被取出，但是处理总数、成功上传数以及过滤数据量不变，这就引起我的怀疑了。
然后查看downloader-sender 模块的日志没有动，好像阻塞在某个地方是的，这个时候通过日志就无法进一步排查问题了。

JVM 工具排查

  对于线上问题，首先最简单的就是通过日志排查，但是有些从日志里排查不出问题，就比如像👆，日志没有输出，难道就干瞪眼？难道就重启？解决问题的时候一定要冷静不要着急。阿里大佬推出一款Java 线上排查问题的利器Arthas 有兴趣可以了解下，我这里并没有使用。我使用的是JVM自带的工具。
  JVM 自带的工具有很多，我当时是这么思考的，我想知道当前线程池的线程在干嘛？阻塞住了？阻塞在哪里？在代码的第几行？然后我才能有针对性的去解决问题。因此我要找一款可以打印出Java 堆栈的工具，大家估计也猜到了就是jstack——Java 堆栈跟踪工具。使用jstack 很简单:只需执行命令jstack PID 就会在终端输出我们熟悉的堆栈信息。从堆栈信息中我发现线程池中的线程都停留在一个 read 函数上，因为过去很长时间我找不到当时的堆栈照片，这个read 函数就是我们封装的下载函数使用Java原生的HttpURLConnection这个类的读和写都是阻塞的，如果没有设置读超时时间，在网络不稳定的情况下，读取操作可能就会一直阻塞，当时我不能确定就是这个原因，因为jstack 打印的是虚拟机线程的堆栈快照，即在那一瞬间的线程堆栈，所以我就重复执行了下jstack PID 命令,发现线程池里的堆栈还在那个位置。
  当时我就纳闷一个问题：上文我们说到 fetch data 会将数据放到一个给定长度的阻塞队列中，downloader-sender 不停地取出给线程池去处理，从👆的日志可以看出，阻塞队列的size一直是变化的,说明有生产也有消费,如果线程池取出了数据没有处理放在哪里了呢？这又是线程池的知识，画个草图：

所以需要去构造线程程池代码处看下上图中coreSize,任务队列,maxSize以及拒绝策略是如何配置的。代码很简单,没有任何简化：

private static ExecutorService es = Executors.newFixedThreadPool(50);

有点经验的人估计都已经知道问题出现在哪里了。下面我们看看newFixedThreadPool 方法

 public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, //coreSize 核心线程数
                                      nThreads, //maxSize 线程池所能创建的最大线程数
                                      0L, //线程池中线程的空闲时间：如果线程空闲超过这个时间就被回收
                                    TimeUnit.MILLISECONDS,//空闲时间单位
                                      new LinkedBlockingQueue<Runnable>()
                                     //任务队列,LinkedBlockingQueue 默认会构建一个无界的阻塞队列
                                    ); 
    }

通过以上分析，我们可以分析出问题：由于线程池的任务队列是无限大的,所以上文日志可以看出缓冲数据队列的大小可以不断变化，但是到线程池中，由于线程下载图片的时候阻塞住了,所以导致所有的数据都堆积在线程池的任务队列中。

解决方法

  

• 下载图片的方法: 设置读超时时间，默认设置为5s
• 手动调用ThreadPoolExecutor 构建器创建线程池，设置任务队列的长度为10000

   重新打包运行的时候就发现有较多读超时的日志，正好验证了我们的答案。

后记

   优化后的程序还有问题么？答案是有的，因为再完美的你，明天之后你会发现今天的你并不完美。好像与面试没有关系？no,阻塞和非阻塞，线程池的知识是面试官们比较喜欢问的，你可能在面试的时候疑惑以后直接用便得了为啥需要知道这么清楚，现在知道了吧。