【经验篇】在写并发代码时，应该注意些什么呢？

最新推荐文章于 2022-10-17 11:45:52 发布

Java知识日历

最新推荐文章于 2022-10-17 11:45:52 发布

阅读量240

点赞数

文章标签：数据库多线程 java python linux

由于多核多线程的CPU的诞生，多线程、高并发的编程越来越受重视和关注。多线程可以给程序带来如下好处。

多线程的好处

1.充分利用CPU的资源

从上面的CPU的介绍，可以看的出来，现在市面上没有CPU的内核不使用多线程并发制的，特别是服务器还不止一个CPU，如果还是使用单线程的技术做思路，明显就out了。因为程序的基本调度单元是线程，并且一个线程也只能在一个CPU的一个核的一个线程跑，如果你是一个i3的CPU的话，最差也是双核心4线程的运算能力；如果是一个线程的程序的话，那是要浪费3/4的CPU性能；如果设计一个多线程的程序的话，那它就可以同时在多个CPU的多个核的多个线程上跑，可以充分地利用CPU，减少CPU的空闲时间，发挥它的运算能力，提高并发量。

就像我们平时坐地铁一样，很多人坐长线地铁的时候都在认真看书，而不是为了坐地铁而坐地铁，到家了再去看书，这样你的时间就相当于有了两倍。这就是为什么有些人时间很充裕，而有些人老是说没时间的一个原因，工作也是这样，有的时候可以并发地去做几件事情，充分利用我们的时间，CPU也是一样，也要充分利用。

2.加快响应用户的时间

比如我们经常用的迅雷下载，都喜欢多开几个线程去下载，谁都不愿意用一个线程去下载，为什么呢？答案很简单，就是多个线程下载快啊。我们在做程序开发的时候更应该如此，特别是我们做互联网项目，网页的响应时间若提升ls，如果流量大的话，就能增加不少转换量。做过高性能web前端调优的都知道，要将静态资源地址用两三个子域名去加载，为什么？因为每多一个子域名，浏览器在加载你的页面的时候就会多开几个线程去加载你的页面资源，提升网站的响应速度。多线程，高并发真的是无处不在。

3.可以使你的代码模块化，异步化，简单化

例如我们在做Android程序开发的时候，主线程的UI展示部分是一块主代码程序部分，但是UI上的按钮用相应事件的处理程序就可以做个单独的模块程序拿出来。这样既增加了异步的操作，又使程序模块化，清晰化和简单化。时下最流行的异步程序处理机制，正是多线程、并发程序最好的应用例子。相信多线程应用开发的好处还有很多，大家在日后的代码编写过程中可以慢慢体会它的魅力所在。

应该注意些什么呢？

获取单例对象需要保证线程安全，其中的方法也要保证线程安全。

单例对象会被多线程共享，因此要保证它是线程安全的，它其中的方法都要保证是线程安全的。
工具类、资源驱动类、单例工厂类都要注意这个问题。

创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。

线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者 “过度切换” 的问题。

线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

FixedThreadPool 和 SingleThreadPool: 允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
CachedThreadPool 和 ScheduledThreadPool: 允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。

SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为 static，必须加锁，或者使用 DateUtils 工具类。

如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar， DateTimeFormatter 代替 Simpledateformatter。

高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁; 能锁区块，就不要锁整个方法体; 能用对象锁，就不要用类锁。

对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。

线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是 A、B、C，否则可能出现死锁。

并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。

如果每次访问冲突概率小于 20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于 3 次。

多线程并行处理定时任务时，Timer 运行多个 TimerTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。

使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown 方法，线程执行代码注意 catch 异常，确保 countDown 方法可以执行，避免主线程无法执行至 await 方法，直到超时才返回结果。

请在 try…finally 语句里执行 countDown 方法，与关闭资源类似。

避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一 seed 导致的性能下降。

Random 实例包括 java.util.Random 的实例或者 Math.random() 实例。
在 JDK7 之后，可以直接使用 API ThreadLocalRandom。
在 JDK7 之前，可以把 Random 放在 ThreadLocal 里，只在本线程中使用。

通过双重检查锁 (double-checked locking) 实现延迟初始化的优化问题隐患，只要不是特别老的 JDK 版本(1.4 以下)，双检锁是没问题的。

volatile 解决多线程内存不可见问题。

对于一写多读，是可以解决变量同步问题，但是如果多写，是无法解决线程安全问题的。

如果是 count++ 操作，使用如下类实现:
- AtomicInteger count = new AtomicInteger();
- count.addAndGet(1);
如果是 JDK8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好 (减少乐观锁的重试次数)。

HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中注意规避此风险。

开发程序的时候要预估使用量，根据使用量来设置初始值。

ThreadLocal 无法解决共享对象的更新问题，ThreadLocal 对象建议使用 static 修饰。这个变量是针对一个线程内所有操作共有的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象 (只要是这个线程内定义的) 都可以操控这个变量。

线程之间的死循环过程

为了解决线程之间的安全性引入了Java的锁机制，而一不小心就会产生Java线程死锁的多线程问题，因为不同的线程都在等待那些根本不可能被释放的锁，从而导致所有的工作都无法完成。假设有两个线程，分别代表两个饥饿的人，他们必须共享刀叉并轮流吃饭。他们都需要获得两个锁：共享刀和共享叉的锁。假如线程A获得了刀，而线程B获得了叉。线程A就会进入阻塞状态来等待获得叉，而线程B则阻塞来等待线程A所拥有的刀。这只是人为设计的例子，但尽管在运行时很难探测到，这类情况却时常发生。

线程太多了会将服务器资源耗尽形成死机当机

线程数太多有可能造成系统创建大量线程而导致消耗完系统内存以及CPU的“过渡切换” 造成系统的死机，那么我们该如何解决这类问题呢？某些系统资源是有限的，如文件描述符。多线程程序可能耗尽资源，因为每个线程都可能希望有一个这样的资源。如果线程数相当大，或者某个资源的侯选线程数远远超过了可用的资源数，则最好使用。一个最好的示例是数据库连接池。只要线程需要使用一个数据库连接，它就从池中取出一个，使用以后再将它返回池中。资源池也称为。这里先有一个概念，后面会逐渐讲到线程池的概念。