作者:王炸 |【坚持1000篇原创】
?2019.12.18 第58篇原创?
☝️先赞后看是技术人的传统美德☝️
一个懂天文学的程序员
拥有8年一线大厂经验,兴趣广泛,欢迎和我边玩边学,从今天起面朝大海。
我们的座右铭:“要好好学习,不然别人只会指着你的鼻子说“你看那个人,除了帅,一无是处。”
北京时间22:00,我丝毫没想下班的冲动,献身程序员改变世界的伟大工程,身处望京一代最高档的写字楼内,窗外星光璀璨、五彩斑斓、华灯初上、光彩夺目、流光溢彩、灯火齐明、暮色弥漫,我实在找不到一个准确的词形容这座美丽的城市,只能感叹:“鸡你太美”。
我在公司内部最高端的千人技术群里看到一个安全技术专家分享的代码安全经验,整理成册,记得点赞转发
多线程能并发的处理多个任务,有效地提高复杂应用程序的性能,在实际开发中扮演着十分重要的角色。但是线程也带来了很多风险,并且由线程引起的问题往往在测试中难以发现,到了线上就会造成重大的故障和损失。本文主要结合一些线程使用过程中的CaseStudy,梳理总结常犯的线程安全问题和最佳实践分享给大家。由于个人时间和水平有限,文中不足之处请老司机们指正。
//int count=10;表示商品剩余库存
public int decrement(){
return --count;
}
在单线程环境下,这个方法能正确工作,但在多线程环境下,就会导致错误的结果。“--count”看上去是一个操作,但实际上它包含三步(读取-修改-写入):读取count的值、将值减1、最后把计算结果赋值给count。
如下图展示了一种错误的执行过程,当有两个线程A、B同时执行该方法时,它们读取到count的值都是10,最后返回结果都是9;
意味着可能有两个人购买了商品,但库存却只减了1,这对于真实的生产环境是不可接受的。
预期结果应该是8呀,臣妾如何能接受?
像上面例子这样由于不恰当的执行时序导致不正确结果的情况,是一种很常见的并发安全问题,被称为竞态条件。避免这种问题,需要保证“读取-修改-写入”这样复合操作的原子性。
在Java中,有很多方式可以实现,比如使用***synchronize***内置锁或**ReentrantLock显式锁的加锁机制、使用线程安全的原子类、以及采用CAS的方式等。
面试中经常被问:来,说说你知道的Java中的锁?。
某个操作因为阻塞或循环,无法继续执行下去。例如在多线程应用中,线程A在等待线程B释放其占有的资源,但线程B一直不释放该资源,线程A就要永久的等待下去。多线程编程中可能出现的活跃性问题有死锁、饥饿、以及活锁等;其中最常见的是死锁问题,如下图,多个线程之间相互等待获取对方的锁,又不会释放自己占有的锁,而导致阻塞使得这些线程无法运行下去就是死锁,它往往是不正确的使用加锁机制以及线程间执行顺序的不可预料性引起的。
尽量减少锁的使用或者作用范围,例如使用synchronize关键字时,尽量不要用synchronize修饰整个方法,只锁住方法中几行需要同步的代码块;还有使用定时锁,如ReentrantLock,在tryLock获取锁时指定超时时间timeout,获取锁的时间超过timeout就可以抛出异常,来中断线程避免其一直阻塞下去。
就这么说吧,设计好的并发应用程序中,线程能提升程序的性能,设计不好还不如不用多线程,,因为线程本身的创建、以及线程之间的切换都要消耗资源,如果频繁的创建线程或者CPU在线程调度花费的时间远大于线程运行的时间,使用线程反而得不偿失,甚至造成CPU负载过高或者OOM的后果。
看一段代码
import java.util.*;
import java.util.concurrent.*;
/*
* @desc java集合中Fast-Fail的测试程序。
*
* fast-fail事件产生的条件:当多个线程对Collection进行操作时,若其中某一个线程通过iterator去遍历集合时,该集合的内容被其他线程所改变;则会抛出ConcurrentModificationException异常。
* fast-fail解决办法:通过util.concurrent集合包下的相应类去处理,则不会产生fast-fail事件。
*
* 本例中,分别测试ArrayList和CopyOnWriteArrayList这两种情况。ArrayList会产生fast-fail事件,而CopyOnWriteArrayList不会产生fast-fail事件。
* (01) 使用ArrayList时,会产生fast-fail事件,抛出ConcurrentModificationException异常;定义如下:
* private static List<String> list = new ArrayList<String>();
* (02) 使用时CopyOnWriteArrayList,不会产生fast-fail事件;定义如下:
* private static List<String> list = new CopyOnWriteArrayList<String>();
*
* @author skywang
*/
public class FastFailTest {
private static List<String> list = new ArrayList<String>();
//private static List<String> list = new CopyOnWriteArrayList<String>();
public static void main(String[] args) {
// 同时启动两个线程对list进行操作!
new ThreadOne().start();
new ThreadTwo().start();
}
private static void printAll() {
System.out.println("");
String value = null;
Iterator iter = list.iterator();
while(iter.hasNext()) {
value = (String)iter.next();
System.out.print(value+", ");
}
}
/**
* 向list中依次添加0,1,2,3,4,5,每添加一个数之后,就通过printAll()遍历整个list
*/
private static class ThreadOne extends Thread {
public void run() {
int i = 0;
while (i<6) {
list.add(String.valueOf(i));
printAll();
i++;
}
}
}
/**
* 向list中依次添加10,11,12,13,14,15,每添加一个数之后,就通过printAll()遍历整个list
*/
private static class ThreadTwo extends Thread {
public void run() {
int i = 10;
while (i<16) {
list.add(String.valueOf(i));
printAll();
i++;
}
}
}
}
当某一个线程A通过iterator去遍历某集合的过程中,若该集合的内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件。活生生的例子。
不要小看这个问题,ConcurrentModificationException足可以让你的整个进程挂掉,我遇到过真实的Case,发生在凌晨4点。
当时是使用多线程安全的工具类,如CopyOnWriteArrayList、ConcurrentHashMap等并发容器,AtomicBoolean、AtomicInteger等原子类,以及阻塞队列、线程池等等。日常开发中推荐使用这些工具类来实现多线程编程。
啥意思呢?看代码
Lock lock = new ReentrantLock();
...
try{
lock.tryLock(timeout, TimeUnit.MILLISECONDS)
//业务逻辑
}
catch (Exception e){
//错误日志
//抛出异常或直接返回
}
finally {
lock.unlock();
}
就是保证你的 tryLock 和 unlock是成对出现,不然迟早死翘翘,因无法获取锁而阻塞最终线程池被打满。
正确姿势:
public class ThreadPool {
private ThreadPool() {
}
public static ExecutorService ACTIVITY_POOL = new ExecutorServiceTraceWrapper(Executors.newFixedThreadPool(1, new ThreadFactoryBuilder().setNameFormat("demo").build()));
}
错误姿势:
在for循环中创建线程池,犯忌讳。这样会导致线程池占用的内存会越来越多,就会导致频繁fullGC甚至OOM。
错误姿势:
Executors.newFixedThreadPool(int); //创建固定容量大小的线程池 Executors.newSingleThreadExecutor(); //创建容量为1的线程池 Executors.newCachedThreadPool(); //创建一个线程池,线程池容量大小为Integer.MAX_VALUE
JDK的默认线程池对资源使用基本没做什么限制,如果生成环境中请求量很高或者出现故障时,就容易导致线程阻塞、资源耗尽,出现OOM等问题。
正确姿势:
new ThreadPoolExecutor(1, 10, 60L, TimeUnit.SECONDS, new SynchronousQueue());
有态度,对代码存敬畏之心。