《2020 Offer收割机》| 线程安全法则

王炸

发布于 2019-12-25 14:40:07

4580

发布于 2019-12-25 14:40:07

文章被收录于专栏：转行程序员转行程序员转行程序员

一个优秀程序员的最大的美德是懒惰
授你以鱼不如授你以渔
王炸不教你技术，只教你学技术

作者：王炸 |【坚持1000篇原创】

?2019.12.18 第58篇原创?

☝️先赞后看是技术人的传统美德☝️

关于王炸

一个懂天文学的程序员

拥有8年一线大厂经验，兴趣广泛，欢迎和我边玩边学，从今天起面朝大海。

我们的座右铭：“要好好学习，不然别人只会指着你的鼻子说“你看那个人，除了帅，一无是处。”

言归正传

格局决定一切思考决定成败 | 为什么会写此文？

北京时间22:00，我丝毫没想下班的冲动，献身程序员改变世界的伟大工程，身处望京一代最高档的写字楼内，窗外星光璀璨、五彩斑斓、华灯初上、光彩夺目、流光溢彩、灯火齐明、暮色弥漫，我实在找不到一个准确的词形容这座美丽的城市，只能感叹：“鸡你太美”。

我在公司内部最高端的千人技术群里看到一个安全技术专家分享的代码安全经验，整理成册，记得点赞转发

1.引言

多线程能并发的处理多个任务，有效地提高复杂应用程序的性能，在实际开发中扮演着十分重要的角色。但是线程也带来了很多风险，并且由线程引起的问题往往在测试中难以发现，到了线上就会造成重大的故障和损失。本文主要结合一些线程使用过程中的CaseStudy，梳理总结常犯的线程安全问题和最佳实践分享给大家。由于个人时间和水平有限，文中不足之处请老司机们指正。

2.有风险的线程|危险的边缘试探

2.1 多线程执行顺序不确定性

//int count=10；表示商品剩余库存
public int decrement(){
	return --count;
}

在单线程环境下，这个方法能正确工作，但在多线程环境下，就会导致错误的结果。“--count”看上去是一个操作，但实际上它包含三步（读取-修改-写入）：读取count的值、将值减1、最后把计算结果赋值给count。

如下图展示了一种错误的执行过程，当有两个线程A、B同时执行该方法时，它们读取到count的值都是10，最后返回结果都是9；

意味着可能有两个人购买了商品，但库存却只减了1，这对于真实的生产环境是不可接受的。

预期结果应该是8呀，臣妾如何能接受？

像上面例子这样由于不恰当的执行时序导致不正确结果的情况，是一种很常见的并发安全问题，被称为竞态条件。避免这种问题，需要保证“读取-修改-写入”这样复合操作的原子性。

解决办法：使用锁

在Java中，有很多方式可以实现，比如使用***synchronize***内置锁或**ReentrantLock显式锁的加锁机制、使用线程安全的原子类、以及采用CAS的方式等。

面试中经常被问：来，说说你知道的Java中的锁?。

2.2 线程死锁问题

某个操作因为阻塞或循环，无法继续执行下去。例如在多线程应用中，线程A在等待线程B释放其占有的资源，但线程B一直不释放该资源，线程A就要永久的等待下去。多线程编程中可能出现的活跃性问题有死锁、饥饿、以及活锁等；其中最常见的是死锁问题，如下图，多个线程之间相互等待获取对方的锁，又不会释放自己占有的锁，而导致阻塞使得这些线程无法运行下去就是死锁，它往往是不正确的使用加锁机制以及线程间执行顺序的不可预料性引起的。

解决办法：

尽量减少锁的使用或者作用范围，例如使用synchronize关键字时，尽量不要用synchronize修饰整个方法，只锁住方法中几行需要同步的代码块；还有使用定时锁，如ReentrantLock，在tryLock获取锁时指定超时时间timeout，获取锁的时间超过timeout就可以抛出异常，来中断线程避免其一直阻塞下去。

2.3 多线程性能问题|多线程一定能让性能飞起来吗？

就这么说吧，设计好的并发应用程序中，线程能提升程序的性能，设计不好还不如不用多线程，，因为线程本身的创建、以及线程之间的切换都要消耗资源，如果频繁的创建线程或者CPU在线程调度花费的时间远大于线程运行的时间，使用线程反而得不偿失，甚至造成CPU负载过高或者OOM的后果。

怎么办？解决办法：答案可能是使用线程池吧。

3.线程安全编码规范|从危险的边缘拉上岸

3.1 多线程不用不安全集合，不安全集合不要多线程

看一段代码

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等原子类，以及阻塞队列、线程池等等。日常开发中推荐使用这些工具类来实现多线程编程。

3.2 无unlock不tryLock

啥意思呢？看代码

Lock lock = new ReentrantLock();
...
try{
  lock.tryLock(timeout, TimeUnit.MILLISECONDS)
  //业务逻辑
}
catch (Exception e){
  //错误日志
  //抛出异常或直接返回
}
finally {
  lock.unlock();
}

就是保证你的 tryLock 和 unlock是成对出现，不然迟早死翘翘，因无法获取锁而阻塞最终线程池被打满。

4.线程池正确使用姿势

4.1 线程池创建就要写成全局变量

正确姿势：

public class ThreadPool {
    private ThreadPool() {
    }

    public static ExecutorService ACTIVITY_POOL = new ExecutorServiceTraceWrapper(Executors.newFixedThreadPool(1, new ThreadFactoryBuilder().setNameFormat("demo").build()));

}

错误姿势：

在for循环中创建线程池，犯忌讳。这样会导致线程池占用的内存会越来越多，就会导致频繁fullGC甚至OOM。

4.2 谨慎使用 ThreadPoolExecutor

错误姿势：

Executors.newFixedThreadPool(int); //创建固定容量大小的线程池 Executors.newSingleThreadExecutor(); //创建容量为1的线程池 Executors.newCachedThreadPool(); //创建一个线程池，线程池容量大小为Integer.MAX_VALUE

newFixedThreadPool 创建的线程池 corePoolSize 和 maximumPoolSize 值是相等的，使用的阻塞队列是LinkedBlockingQueue。
newSingleThreadExecutor 将 corePoolSize 和 maximumPoolSize 都设置为1，也使用的 LinkedBlockingQueue。LinkedBlockingQueue默认容量为Integer.MAX_VALUE=2147483647，对于真正的机器来说，可以被认为是无界队列。
newFixedThreadPool 和 newSingleThreadExecutor 在运行的线程数超过 corePoolSize 时，后来的请求会都被放到阻塞队列中等待，因为阻塞队列设置的过大，后来请求不能快速失败而长时间阻塞，就可能造成请求端的线程池被打满，拖垮整个服务。
newCachedThreadPool 将 corePoolSize 设置为0，将 maximumPoolSize 设置为 Integer.MAX_VALUE，阻塞队列使用的 SynchronousQueue，SynchronousQueue 不会保存等待执行的任务。所以 newCachedThreadPool 是来了任务就创建线程运行，而 maximumPoolSize 相当于无限的设置，使得创建的线程数可能会将机器内存占满。

JDK的默认线程池对资源使用基本没做什么限制，如果生成环境中请求量很高或者出现故障时，就容易导致线程阻塞、资源耗尽，出现OOM等问题。

正确姿势：

new ThreadPoolExecutor(1, 10, 60L, TimeUnit.SECONDS, new SynchronousQueue());

总结：

有态度，对代码存敬畏之心。

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2019-12-18，如有侵权请联系 cloudcommunity@tencent.com 删除

编程算法

linux

本文分享自转行程序员微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

编程算法

linux

登录后参与评论

0 条评论

热度