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

来自网络侵删

背景

记得是今年3月份初的事情,我一个同事在之前写的一个程序receiverreceiver主要是从第三方厂家接收数据,下载对应的图片,然后发给我们自己的产品。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一直是变化的,说明有生产也有消费,如果线程池取出了数据没有处理放在哪里了呢?这又是线程池的知识,画个草图:
image.png
所以需要去构造线程程池代码处看下上图中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,阻塞和非阻塞,线程池的知识是面试官们比较喜欢问的,你可能在面试的时候疑惑以后直接用便得了为啥需要知道这么清楚,现在知道了吧。

  • 2
    点赞
  • 10
    收藏
  • 打赏
    打赏
  • 3
    评论
<p> <b><span style="font-size:14px;"></span><span style="font-size:14px;background-color:#FFE500;">【Java面试宝典】</span></b><br /> <span style="font-size:14px;">1、68讲视频课,500道大厂Java常见面试题+100个Java面试技巧与答题公式+10万字核心知识解析+授课老师1对1面试指导+无限次回放</span><br /> <span style="font-size:14px;">2、这门课程基于胡书敏老师8年Java面试经验,调研近百家互联网公司及面试官的问题打造而成,从筛选简历和面试官角度,给出能帮助候选人能面试成功的面试技巧。</span><br /> <span style="font-size:14px;">3、通过学习这门课程,你能系统掌握Java核心、数据库、Java框架、分布式组件、Java简历准备、面试实战技巧等面试必考知识点。</span><br /> <span style="font-size:14px;">4、知识点+项目经验案例,每一个都能做为面试的作品展现。</span><br /> <span style="font-size:14px;">5、本课程已经在线下的培训课程中经过实际检验,老师每次培训结束后,都能帮助同学们运用面试技巧,成功找到更好的工作。</span><br /> <br /> <span style="font-size:14px;background-color:#FFE500;"><b>【超人气讲师】</b></span><br /> <span style="font-size:14px;">胡书敏 | 10年大厂工作经验,8年Java面试官经验,5年线下Java职业培训经验,5年架构师经验</span><br /> <br /> <span style="font-size:14px;background-color:#FFE500;"><b>【报名须知】</b></span><br /> <span style="font-size:14px;">上课模式是什么?</span><br /> <span style="font-size:14px;">课程采取录播模式,课程永久有效,可无限次观看</span><br /> <span style="font-size:14px;">课件、课程案例代码完全开放给你,你可以根据所学知识,自行修改、优化</span><br /> <br /> <br /> <span style="font-size:14px;background-color:#FFE500;"><strong>如何开始学习?</strong></span><br /> <span style="font-size:14px;">PC端:报名成功后可以直接进入课程学习</span><br /> <span style="font-size:14px;">移动端:<span style="font-family:Helvetica;font-size:14px;background-color:#FFFFFF;">CSDN 学院APP(注意不是CSDN APP哦)</span></span> </p>

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:创作都市 设计师:CSDN官方博客 返回首页
评论 3

打赏作者

Unyielding ● L

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值