记一次生产事故

服务器故障排除

前言:下次测试的时候我还是先做个镜像吧

博主刚到这家公司,项目是之前外包做的,就我一个JAVA软件工程师,服务器也是外包公司运维配置,使用的是docker swarm+consul+ rabbitMQ+mysql5.7,项目为ssm框架,碰巧没用过docker ,但是原理还是一样,在tomcat下部署项目

3月26号上午,我想将服务器的docker 端口号开放出来以便之后工作,因为之前两个礼拜的摸索基本上的东西我都已经掌握,就差如何将新增的功能发布到服务器之上,我想到了利用IDEA的docker工具连接远程服务器,再根据自己编写的dockerfiles生成镜像,每次下班前根据镜像部署一次即可,11点半时小程序和后端开时出现异常,返回502错误信息

 当时心理活动:我开放了个端口,下载了个net-tools,怎么就这样了,怎么办,心里慌得一比,服务器不是都应该开启防火墙的嘛?

firewalld-cmd 之前未启动被我开启,不对不对,就算是异常也应该是404,不应该是502

在这个过程中我仔细思考了一会:会不会是系统资源耗尽了,查看了top,8G内存还剩100来M,好家伙,我还以为是我的问题

什么原因会出下这种问题呢??

内存泄漏是当前首要排查对象,查看了阿里云日志,观察了当前进程,最终确定程序应该是崩溃了,

解决思路:

毕竟刚来不久,不敢乱修改原本之前已经定义好的脚本和各种配置,于是我将服务器重启了一次,关闭了firewalld-cmd

,发现内存溢出的问题以解决,,而且小程序可以访问,但是新的问题随之出现
 后台登录不上,打开F12,发现权限认证500,是不是程序已经崩了。。。反正我刚好把docker学会,就利用阿里云之前留下来的镜像文件pull到服务器之上,然后删除已经出错的容器,再次新建了一个,果然,程序已然跑通

心得:不慌,先看实际问题再具体分析,知道问题的源头才好解决

这次的文章标题原本想叫《一次因错用HashMap造成的生产BUG》,但作者觉得这个标题可能会让人联想到某些Java公众号写的标题党文章,所以改成了现在这个标题。在文章中,作者承认在A接口中将所有产品都放到HashMap中并不太规范,但在实际实现中是可行的,所以并不算是“错用”。然而,作者在写代码时疏忽了缓存的问题,忽视了HashMap在多线程环境下不能使用的要求,结果写出了有BUG的代码。 作者从这次线上BUG中学到了几个教训:首先,在使用直接存放对象引用的内存缓存时,要注意不要修改从缓存中获取的内容;其次,在修改代码时,要全面考虑前后逻辑,思考修改的后果;再次,不要困于思维陷阱,在寻找问题时不一定问题出在前面的代码;最后,遇到解决不了的问题时,寻求帮助是很重要的,领导在几分钟内就发现了作者几个小时都没找到的BUG。 问题出现在addDisplayStyle()方法中。当有多个APP请求A接口时,业务线程执行到product.put("displayStyle", displayStyle)这行代码时,实际上是在往同一个Map中放入元素。由于key相同,就会发生哈希冲突。如果此时某个Map的元素个数达到了扩容条件,就会触发扩容,并有可能出现链表成环的情况。当有新的请求到来时,工作线程执行到recommends = deduplicateAndGetFirstN(recommends, 3)这行代码。 综上所述,这次的文章是关于作者经历的一次因错用HashMap而导致生产BUG的经历。作者从中学到了关于使用缓存、修改代码、寻找问题和寻求帮助等方面的教训。问题出现在addDisplayStyle()方法中,当多个APP请求A接口时,可能会触发HashMap的扩容并导致链表成环的情况。<span class="em">1</span><span class="em">2</span><span class="em">3</span><span class="em">4</span>
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值