线程安全

ruanjianershu

本文主要记录最近在解决一个兄弟的代码bug中的几点比较突出的问题.

多线程注意事项
1、HashMap 不是线程安全的

在使用多线程的时候 , 一定要注意自己所使用和设计的数据结构是否是线程安全的.
比如 Java中平时用的最多的Map集合就是HashMap了,它是线程不安全的
为了避免出现线程安全的问题,不能使用HashMap作为成员变量,要寻求使用线程安全的Map 如 HashTable 、SynchronizedMap、ConcurrentHashMap ; 当然,也可以自己写锁来控制hashMap的安全. eg: 读写锁

如下,是我们现成的项目中的代码,多线程的参数传递,使用了HashMap,导致了很大的生产事故
image.png

2、多线程在进行对象的拷贝时,务必使用深拷贝形式
image.png

存在对象时 , 建议使用序列化对象的方式进行深拷贝 . 因为对象的数据结构较为复杂 , hashMap的putAll() 甚至是apache开源的CloneUtils.clone() 都不可能完全正确的进行深拷贝.

2.1 此处,插播一个问题,不知道大家注意到没有,上面的代码中,HashMap 在进行初始化的时候,并没有指定map的大小,这里也就出了一个新的问题: 服务一直在占用高CPU

HashMap 在并发的环境下进行rehash的时候会造成链表的闭环,因此在进行get()操作的时候导致了CPU占用100% . 
为什么进行rehash ?  具体去看源码 , 大概就是map的大小触碰到了HashMap的阈值threshold(map实现的时候就有了),当HashMap的容量达到  threshold    时就需要进行扩容,这个时候就要进行ReHash操作了,可以看addEntry函数的实现,当size达到threshold时会调用 resize 进行扩容

2.2 在排查CPU 占用的问题的时候,我们定位到一个jdk的bug : Selector BUG
下面我们对这个进行一个讲解

2.2.1 Selector BUG出现的原因
     Selector的轮询结果为空,也没有wakeup或新消息处理,则发生空轮询,CPU使用率100%,(因为selector的select方法,返回numKeys是0,所以下面本应该对key值进行遍历的事件处理根本执行不了,又回到最上面的while(true)循环,循环往复,不断的轮询,直到linux系统出现100%的CPU情况,其它执行任务干不了活)

image.png

2.2.2 Netty的解决办法
    对Selector的select操作周期进行统计,每完成一次空的select操作进行一次计数
    若在某个周期内连续发生N(默认是512)次空轮询,则触发了epoll死循环bug
    重建Selector,判断是否是其他线程发起的重建请求,若不是则将原SocketChannel从旧的Selector上去除注册,重新注册到新的Selector上,并将原来的Selector关闭。 
2.2.3 该bug相关信息
  https://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719
  https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933
  这个bug的描述内容为,在NIO的selector中,即使是关注的select轮询事件的key为0的话,NIO照样不断的从select本应该阻塞的情况中wake up出.

3、发现Cpu 打满 常用命令(三板斧)

1、top命令,按P按照CPU使用率排序找到占用率最高的进程pid
2、top -Hp pid 命令找到占用率最高的线程tid
3、printf "%x\n" tid 命令把十进制线程tid转化为十六进制
4、jstack -l tid > stack.txt 打印栈信息
5、用十六进制的tid在堆栈信息中搜索
6、如果没有搜索到,重复执行几遍第4步,一定能有

本文参考: https://pdai.tech/md/java/io/...

阅读 406

人行天地间 忽如远行客

9 声望
4 粉丝
0 条评论

人行天地间 忽如远行客

9 声望
4 粉丝
文章目录
宣传栏