一个优秀程序员的最大的美德是懒惰
授你以鱼不如授你以渔
王炸不教你技术，只教你学技术
作者：王炸 |【坚持1000篇原创】
2019.12.18 第58篇原创
☝️先赞后看是技术人的传统美德☝️
关于王炸
一个懂天文学的程序员
拥有8年一线大厂经验，兴趣广泛，欢迎和我边玩边学，从今天起面朝大海。
我们的座右铭：“要好好学习，不然别人只会指着你的鼻子说“你看那个人，除了帅，一无是处。”
言归正传
格局决定一切 思考决定成败 | 为什么会写此文？
北京时间22:00，我丝毫没想下班的冲动，献身程序员改变世界的伟大工程，身处望京一代最高档的写字楼内，窗外星光璀璨、五彩斑斓、华灯初上、光彩夺目、流光溢彩、灯火齐明、暮色弥漫，我实在找不到一个准确的词形容这座美丽的城市，只能感叹：“鸡你太美”。
我在公司内部最高端的千人技术群里看到一则招聘信息，这则招聘信息引发了我的关注，于是有了《一则技术专家招聘要求引发的深度思考》一文。
1.引言
多线程能并发的处理多个任务，有效地提高复杂应用程序的性能，在实际开发中扮演着十分重要的角色。但是线程也带来了很多风险，并且由线程引起的问题往往在测试中难以发现，到了线上就会造成重大的故障和损失。本文主要结合一些线程使用过程中的CaseStudy，梳理总结常犯的线程安全问题和最佳实践分享给大家。由于个人时间和水平有限，文中不足之处请老司机们指正。
2.有风险的线程|危险的边缘试探
2.1 多线程执行顺序不确定性
//int count=10； 表示商品剩余库存publicintdecrement(){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 多线程不用不安全集合，不安全集合不要多线程
看一段代码
当某一个线程A通过iterator去遍历某集合的过程中，若该集合的内容被其他线程所改变了；那么线程A访问集合时，就会抛出ConcurrentModificationException异常，产生fail-fast事件。活生生的例子。
不要小看这个问题，ConcurrentModificationException足可以让你的整个进程挂掉，我遇到过真实的Case，发生在凌晨4点。
怎么解决？
当时是使用多线程安全的工具类，如CopyOnWriteArrayList、ConcurrentHashMap等并发容器，AtomicBoolean、AtomicInteger等原子类，以及阻塞队列、线程池等等。日常开发中推荐使用这些工具类来实现多线程编程。
3.2 无unlock不tryLock
啥意思呢？看代码
Lock lock =newReentrantLock();...try{ lock.tryLock(timeout, TimeUnit.MILLISECONDS)//业务逻辑}catch(Exception e){//错误日志//抛出异常或直接返回}finally{ lock.unlock();}
就是保证你的tryLock和unlock是成对出现，不然迟早死翘翘，因无法获取锁而阻塞最终线程池被打满。
4.线程池正确使用姿势
4.1 线程池创建就要写成全局变量
正确姿势：
publicclassThreadPool{privateThreadPool(){ }publicstaticExecutorService ACTIVITY_POOL =newExecutorServiceTraceWrapper(Executors.newFixedThreadPool(1,newThreadFactoryBuilder().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等问题。
正确姿势：
newThreadPoolExecutor(1,10,60L, TimeUnit.SECONDS,newSynchronousQueue());
总结：
有态度，对代码存敬畏之心。