稳定性可靠性设计--源码篇

浅浅的花香味﹌ 2022-12-20 01:30 136阅读 0赞

正文在下面，先打个广告：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70]

### 文章目录 ###

*  概述
 *  日志与异常告警
 *  空指针异常
 *  入参校验
 *  不变模式
 *   *  Integer
     *  锁
 *  重写equals()方法必须要重写hashCode()方法
 *  线程安全
 *   *  ThreadLocal
     *  注意有些类不是线程安全的
     *  volatile 不能保证原子性
     *  正确的try-cache-finally
     *  锁
 *  不要使用try-cache控制业务逻辑
 *  事务
 *  BigDecimal
 *  正确资源释放
 *  设计模式
 *  池化
 *   *  java线程池
     *  其他线程池
     *  连接池
 *  堆内缓存与堆外缓存
 *  超时与重试
 *  CAS
 *  redis
 *  db

# 概述 #

稳定性可靠性设计计划写4篇文章:

*  源码篇
 *  网络篇
 *  流程篇
 *  架构篇
 *  存储篇
 *  前端篇
 *  大数据计算

本文是第一篇，源码篇。从源码角度来看如何写出稳定性高的系统。

我这里把可靠性的内容也一起讲了，稳定性和可靠性也没必要分的太清，相辅相成的。

其实目前已经有很多很优秀的代码规范可以很好的约束程序员写出可靠的，健壮的，稳定的代码。比如阿里的《泰山版java开发规范》，还有SQL规范等等。  
我这里会挑几个有代表性的案例跟大家介绍一下为什么需要有这些规范，坏味道的代码会带来哪些问题。  
更加详细的编程规范读者可以到网上去下载阿里的java相关的开发规范。

以下文章基本都是[我的个人博客][Link 1]的内容，可以百度搜索我的名字，第一条就是。

# 日志与异常告警 #

参加我的博客: [日志打印规范][Link 2]

# 空指针异常 #

*  基本每个使用到的对象，返回值，都要考虑是否会存在空都情况，做出正确判断。
 *  对于一些情况，当返回空时，可以采用返回非空对象的方式来代替。比如查询数据返回空集合`Collections.emptyList()`；`getOrDefault`方法。
 *  使用 if(null == obj) 而不是 if(obj == null) 来避免不必要的空指针异常

# 入参校验 #

*  服务端不可以相信前端任何输入。需要对入参做严格都校验。
 *  微服务间，下层服务也需要对上层服务都入参做校验，不要以为调用方都是一个部门或公司的就忽略了
 *  对于批量操作，务必对请求都数据量做校验，避免大SQL或内存撑爆

# 不变模式 #

不变模式最主要都优点就是线程安全。目前流行的响应式编程也广泛应用。  
缺点：不可变类的每一次“改变”都会产生新的对象，因此在使用中不可避免的会产生很多垃圾。

## Integer ##

反例：用 == 判断是否相等

## 锁 ##

反例：被锁对象是不变模式都对象

[关于Integer数值比较的问题以及不可变对象][Integer]

# 重写equals()方法必须要重写hashCode()方法 #

[JDK11源码–HashMap源码分析][JDK11_HashMap]

# 线程安全 #

## ThreadLocal ##

*  [ThreadLocal内存泄露原因分析][ThreadLocal]
 *  [ThreadLocal 内存泄漏 代码演示 实例演示][ThreadLocal _ _]
 *  [InheritableThreadLocal：子线程继承父线程的本地变量][InheritableThreadLocal]
 *  [当InheritableThreadLocal遇到线程池：主线程本地变量修改后，子线程无法读取到新值][InheritableThreadLocal 1]
 *  [transmittable-thread-local:解决线程池之间ThreadLocal本地变量传递的问题][transmittable-thread-local_ThreadLocal]

## 注意有些类不是线程安全的 ##

*  SimpleDateFormat  
    SimpleDateFormat不是线程安全的，这是常见的错误。需要使用threadlocal或者每次new。  
    建议java8使用 DateTimeFormatter（This class is immutable and thread-safe.）
 *  Random  
    解决方法仍然是threadlocal，java7以后提供了ThreadLocalRandom

当然还有后很多其他的，这里只是抛砖引玉，确保线程安全性

## volatile 不能保证原子性 ##

## 正确的try-cache-finally ##

在以下场景中【CountDownLatch/CyclicBarrier/循环任务/线程池】，需要保证每次任务执行，每次循环都要try-cache，确保必要的资源回收以及任务之间不影响（当然还要具体业务具体分析）。

## 锁 ##

*  不可变对象

private Integer i;
    //代码省略
    synchronized (i){ ...}

*  锁的范围尽可能小，但也不要在for循环内加锁
 *  到底是不是同一把锁？类级别，实例级别， 锁的范围
 *  死锁：如何避免死锁
 *  乐观锁：一定会提升性能吗？适用于什么场景？
 *  读写锁
 *  务必在finally中释放锁

# 不要使用try-cache控制业务逻辑 #

特别注意不要使用具体异常都内容来进行一些业务逻辑判断 [JIT实时编译优化带来的问题：几千次异常以后取不到错误信息了][JIT]

# 事务 #

*  事务使用spring注解@Transactional时，务必添加rollbackFor
 *  多数据源时，务必每个@Transactional都指定数据源，避免遗漏出错
 *  @Transactional失效场景：[6种@Transactional注解的失效场景][6_Transactional]
 *  事务隔离级别

# BigDecimal #

很多同学对BigDecimal都使用姿势是不对的。

*  商业计算使用BigDecimal。构造函数一定要用new BigDecimal(String str)方法。
 *  使用参数类型为String的构造函数或valueOf()方法。但不要传float类型的值，如果不确定，则用new BigDecimal(String str)方法。
 *  BigDecimal都是不可变的（immutable）的，在进行每一步运算时，都会产生一个新的对象，所以在做加减乘除运算时千万要保存操作后的值。
 *  有很多bigdecimal的计算使用的是【BigDecimal.ROUND\_HALF\_DOWN】保留小数位。一般来说使用BigDecimal.ROUND\_HALF\_UP（四舍五入）或者BigDecimal.ROUND\_HALF\_EVEN（银行家算法）比较好。虽然现在业务对精度要求不高，但是还要养成好的习惯
 *  除法需要使用这个签名都方法：java.math.BigDecimal\#divide(java.math.BigDecimal, int, int)
 *  比较使用compareTo而不是equals。除非你如果需要比较小数位都位数

[不要以为你用了BigDecimal后，计算结果就一定精确了][BigDecimal]

# 正确资源释放 #

*  try-finally
 *  try-with-resources
 *  ShutdownHook

# 设计模式 #

设计模式教材很多，自己去看书学习吧。

# 池化 #

## java线程池 ##

建议使用ThreadPoolExecutor来创建线程池。

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue) { 
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), defaultHandler);
    }

实例

new ThreadPoolExecutor(5, 10, 2000, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(100));
    
    new ThreadPoolExecutor(4, 8, 20L, TimeUnit.MINUTES, new LinkedBlockingDeque<>())
    
    //默认拒绝策略
    private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();

CompletableFuture 外部传入线程池。因为默认是fork-join pool，它的默认线程数是CPU核数。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70_pic_center]  
如何确定一个线程池中线程数量？  
N threads = N CPU \* U CPU \* (1 + W/C)  
其中：

*  N CPU 是处理器的核的数目，可以通过 Runtime.getRuntime().availableProce-  
    ssors() 得到
 *  U CPU 是期望的CPU利用率（该值应该介于0和1之间）
 *  W/C是等待时间与计算时间的比率

简单来讲，一般的设置线程池的大小规则是：

*  如果服务是cpu密集型的，设置为电脑的核数
 *  如果服务是io密集型的，设置为电脑的核数\*2

## 其他线程池 ##

tomcat线程池，dubbo线程池等

## 连接池 ##

数据库连接池  
redis连接池

druid网络上推荐配置：

其中特别关心testOnBorrow/testOnReturn/testWhileIdle三个配置。

问题1：maxActive这个参数。**一个数据库连接池到底应该配置多大?**

PostgreSQL提供了一个公式：`连接数 = ((核心数 * 2) + 有效磁盘数)`  
核心数不应包含超线程(hyper thread)，即使打开了hyperthreading也是。如果活跃数据全部被缓存了，那么有效磁盘数是0，随着缓存命中率的下降，有效磁盘数逐渐趋近于实际的磁盘数。这一公式作用于SSD时的效果如何尚未有分析。  
**公理：你需要一个小连接池，和一个充满了等待连接的线程的队列**  
我之前做过的一个日活300W的应用，单机数据库链接也才配置了20。

问题2：数据库上层的应用集群特别多时，如何配置？  
假设数据库最多支持100个链接，你有100台服务器，如何设计呢？难道要每台机器限制1个链接吗？

解决方案一：代理层。

# 堆内缓存与堆外缓存 #

计算缓存内容占用内存空间，考虑GC的影响。  
数据量大时可以考虑堆外缓存。

[Java对象占用堆内存大小计算][Java]

常用换成淘汰策略：

*  FIFO先进先出
 *  LRU（The Least Recently Used，最近最久未使用算法）
 *  LFU（Least Frequently Used ，最近最少使用算法）

[LRU算法在MySQL/hbase/Caffeine 中的优化][LRU_MySQL_hbase_Caffeine]

# 超时与重试 #

连接超时，读超时，写超时

微服务调用链路，a–>b–>c 通常，a掉b的超时时间，要大于b掉c的超时时间。  
重试几次？不重试？退避算法  
幂等

# CAS #

使用CAS要注意ABA问题。  
CAS不适用于高并发的场景，会大大加重CPU负担  
只能保证一个共享变量的原子操作。如果想保证对象中多个变量的原子性，可以使用AtomicReference将过个变量合并为一个变量。或者使用锁。

ABA解决：

*  版本号（适用于持久化的数据库等）
 *  AtomicStampedReference

[java高并发：CAS无锁原理及广泛应用][java_CAS]

# redis #

# db #

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70]: /images/20221120/3d56a8d57bc447319d47ae0fb519ceb1.png
[Link 1]: https://blog.csdn.net/liubenlong007
[Link 2]: https://it007.blog.csdn.net/article/details/110262961
[Integer]: https://blog.csdn.net/liubenlong007/article/details/54613673
[JDK11_HashMap]: https://it007.blog.csdn.net/article/details/87937209
[ThreadLocal]: https://blog.csdn.net/liubenlong007/article/details/107046897
[ThreadLocal _ _]: https://blog.csdn.net/liubenlong007/article/details/107048843
[InheritableThreadLocal]: https://blog.csdn.net/liubenlong007/article/details/107049375
[InheritableThreadLocal 1]: https://blog.csdn.net/liubenlong007/article/details/107049975
[transmittable-thread-local_ThreadLocal]: https://editor.csdn.net/md/?articleId=107050929
[JIT]: https://it007.blog.csdn.net/article/details/108882047
[6_Transactional]: https://blog.csdn.net/m0_37787662/article/details/108222474
[BigDecimal]: https://blog.csdn.net/liubenlong007/article/details/106360977
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20201110175202129.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZneWlidXBp,size_16,color_FFFFFF,t_70#pic_center
[Java]: https://blog.csdn.net/liubenlong007/article/details/103278623
[LRU_MySQL_hbase_Caffeine]: https://it007.blog.csdn.net/article/details/110237332
[java_CAS]: https://it007.blog.csdn.net/article/details/53761730