Java 业务开发常见错误 100 例【完结】

释放双眼,带上耳机,听听看~!

Java 业务开发常见错误 100 例【完结】

Java高手笔记之业务开发常见错误100例

在Web环境中使用ThreadLocal出现数据错乱的坑

原因:线程可能重用,导致ThreadLocal中的数据会串

解决︰用完及时清空数据,比如可以自定义HandlerInterceptorAdapter,在preHandle 的时候去设置ThreadLocal,在 afterCompletion时去remove

使用了ConcurrentHashMap 但还是出现了线程安全问题

原因:ConcurrentHashMap只能保证提供的原子性读写操作(比如putlfAbsent、computelfAbsent、replace、compute)是线程安全的

解决︰如果需要确保多个原子性操作整体线程安全,需要自己加锁解决

补充:诸如size、isEmpty和containsValue 等聚合方法,在并发情况下可能会反映ConcurrentHashMap 的中间状态。因此在并发情况下,这些方法的返回值只能用作参考,而不能用于流程控制

使用了ConcurrentHashMap 但却没有发挥性能优势

原因:仍然像HashMap那样使用加锁的方式,来使用ConcurrentHashMap

解决︰考虑使用computelfAbsent、putlfAbsent、getOrDefault等API来提升性能

在不合适的场景下使用CopyOnWriteArrayList导致的性能问题

原因::CopyOnWriteArrayList每次修改复制一份数据

解决︰读多写少的场景才考虑CopyOnWriteArrayList,写多的场景考虑ArrayList

代码加锁

没有理清楚线程安全问题的所在点,导致锁无效

原因1:没有识别线程安全问题的原因胡乱加锁

原因2∶锁是实例级别的,资源是类级别的,无法有效保护

解决∶明确锁和要保护的资源的关系和范围

加锁没有考虑锁的粒度,可能导致性能问题

原因:加锁粒度太大,使得大段代码整体串行执行,出现性能问题

解决︰尽可能降低锁的粒度,仅对必要的代码块甚至是需要保护的资源本身加锁

加锁没有考虑锁的场景,可能导致性能问题

原因:千篇一律使用写锁,可以根据场景更细化地使用高级锁

解决1:考虑使用StampedLock的乐观读的特性,进—步提高性能

解决2:对于读写比例差异明显的场景,使用ReentrantReadWriteLock 细化区分读写锁

解决3:在没有明确需求的情况下,不要轻易开启公平锁特性

多把锁时,要格外小心死锁问题(VisualVM)

原因:多把锁相互等待对方释放,导致死锁

解决:加锁的时候考虑顺序,按顺序加锁不易死锁

工具:使用VisualVM的线程Dump,查看死锁问题并分析死锁原因

线程池

使用Executors声明线程池导致两种类型的OOM

原因1: newFixedThreadPool使用无界队列,队列堆积太多数据导致OOM

原因2: newCachedThreadPool不限制最大线程数并且使用没有任何容量的SynchronousQueue 作为队列,容易开启太多线程导致OOM

解决:手动new ThreadPoolExecutor,根据需求设置合适的核心线程数、最大线程数、线程回策略、队列、拒绝策略,并对线程进行明确的命名以方便排查问题

线程池线程管理策略详解︰如何实现一个更激进的线程池?

原因:Java的线程池倾向于优先使用队列,队列满了再开启更多线程

解决:重写队列的 offer方法直接返回false,数据不入队列,并且自定义RejectedExecutionHandler,触发拒绝策略的时候再把任务加入队列;参考Tomcat的 ThreadPoolExecutor和TaskQueue类

没有复用线程池,导致频繁创建线程的事故

原因:获取线程池的方法每次都返回一个newCachedThreadPool,好在newCachedThreadPool可以闲置回收

解决︰使用静态字段定义线程池,线程池务必重用

混用线程池,导致性能问题

原因:IO绑定操作和CPU绑定操作混用一个线程池,前者因为负担重,线程长期处于忙的状态,导致CPU操作吞吐受到影响

解决∶根据任务的类型声明合适的线程池,不同类型的任务考虑使用独立线程池

扩展:Java 8的 ParallelStream背后是一个公共线程池,别把IO任务使用ParallelStream来处理

CallerRunsPolicy拒绝策略可能带来的问题

原因:如果设置CallerRunsPolicy,那么被拒绝的任务会由提交任务的线程运行,可能会在线程池满载的情况下直接拖垮整个应用

解决:对于Web和Netty场景,要仔细考虑把任务提交到线程池异步执行使用的拒绝策略,除非有明确的需求,否则不考虑使用CallerRunsPolicy拒绝策略

连接池

你知道常见的Client SDK的API,有哪3种形式吗?

形式1:

内部带有连接池的API: SDK内部会先自动通过连接池获取连接(几乎所有的数据库连接池,都是这一类)

形式2:

连接池和连接分离的API:使用者先通过连接池获取连接,再使用连接执行操作(Jedis)

形式3:

非连接池的API:非线程安全,需要使用者自己封装连接池

在多线程环境下使用Jedis出现的线程安全问题

原因:Jedis是连接池和连接分离的API,Jedis类代表连接,不能多线程环境下使用

解决︰每次使用JedisPool先获取到一个Jedis,然后再调用Jedis 的 API,通过addShutdownHook 来关闭JedisPool

不复用Apache CloseableHttpClient会导致什么问题?(jstack、lsof、Wireshark)

连接池如果不复用,代价可能会比每次创建单个连接还要大:

1、连接池可能每次都会创建一定数量的初始连接

2、连接池可能会有一些管理模块,需要创建单独的线程来管理

工具:

1、使用jstack观察到没有复用连接池,会出现大量的Connection evictor线程

2、使用Isof观察到没有复用连接池,会出现大量TCP连接

3、如果复用CloseableHttpClient,使用wireshark 观察HTTP请求重用一个TCP连接的过程

小心数据库连接池打满后出现的性能问题(JConsole)

原因︰数据库连接池最大连接数设置得太小,很可能会因为获取连接的等待时间太长,导致吞吐量低下甚至超时无法获取连接

解决:对类似数据库连接池的重要资源进行持续检测,并设置一半的使用量作为报警阈值,出现预警后及时扩容

工具:使用JConsole 来观察Hikari连接池的MBean,监控活跃连接、等待线程等数据

扩展:修改配置参数务必验证是否生效,并且在监控系统中确认参数是否生效、是否合理,避免明明使用的是Hikari连接池,却还在调整Druid连接池的参数的情况

HTTP调用

连接超时和读取超时的5个认知误区

误区1:连接超时配置得特别长

分析:连接超时很可能是因为防火墙等原因彻底连接不上,不太会出现连接特别慢的现象,不用设置太长

误区2:排查连接超时问题,却没理清连的是哪里

分析:很可能客户端连接的是Nginx,不是实际的后端服务,从后端服务层面排查问题没用

误区3:认为出现了读取超时,服务端的执行就会中断

分析:客户端读取超时,服务端业务逻辑还会持续运行,不能随意假设服务端处理是失败的

误区4:认为读取超时只是Socket网络层面的概念,是数据传输的最长耗时,故将其配置得非常短

分析:读取超时并不是数据在网络传输的时间,需要包含服务端业务逻辑执行的时间

误区5:认为超时时间越长任务接口成功率就越高,将读取超时参数配置得太长

分析:读取超时设置太长,可能导致上游服务被下游拖垮,应该根据SLA设置合适的读取超时。有些时候,快速失败或熔断不是一件坏事儿

Spring Cloud Feign和 Ribbon配合使用,设置超时的三个坑

坑1

原因:默认情况下Feign的读取超时是1秒,这个时间过于短了

解决︰根据自己的需要设置长一点

坑2

原因:如果要配置Feign的读取超时,就必须同时配置连接超时,才能生效

解决:同时配置readTimeout和connectTimeout

坑3

原因:Ribbon配置连接超时和读取超时的参数大小写和Feign略微不同

解决:Ribbon 使用ReadTimeout和 ConnectTimeout,注意大小写

Spring Cloud Ribbon居然会自动重试我的接?

原因:Ribbon对于HTTP Get请求在一个服务器调用失败后,会自动到下一个节点重试一次

解决︰修改参数,设置ribbon.MaxAutoRetriesNextServer=O;并且对于Get请求需要确保接幂等

小心Apache HttpClient对并发连接数的限制

原因:HttpClient对连接数有限制,默认一个域名2个并发,所有域名20个并发

解决:通过HttpClients.custom( ).setMaxConnPerRoute(10).setMaxConnTotal(20)来设置合适的值

数据库事务

两种错误写法导致Spring声明式事务未生效的两个坑

原因:因为private方法无法代理,所以为private方法设置@Transactional注解无法生效事务

解决:除非使用AspectJ做静态织入,否则需要确保只有public方法才设置@Transactional注解

原因:因为通过this自调用方法不走Spring的代理类,所以无法生效事务

解决︰确保事务性方法从外部通过代理类调用。如果一定要从内部调用,就要重新注入当前类调用

事务即便生效也不一定能回滚的两个情况

情况1

原因:只有异常传播出了标记了@Transactional注解的方法,事务才能回滚

解决︰避免 catch住异常,或者通过TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动回滚

情况2

原因︰默认情况下,出现 RuntimeException(非受检异常)或Error的时候,Spring 才会回滚事务

解决︰设置@Transactional(rollbackFor = Exception.class),来突破默认不回滚受检异常的限制

不出异常,事务居然也不会提交?

原因:默认事务传播策略是REQUIRED,子方法会复用当前事务,子方法出异常后回滚当前事务,导致父方法也无法提交事务

解决︰设置REQUIRES_NEW方式的事务传播策略,让子方法运行在独立事务中

数据库索引

聚簇索引的3个要点

要点1:B+树,既是索引也是数据

要点2:自动创建,只能有一个

要点3:可以加速主键搜索和查询

考虑二级索引的维护、空间和回表代价

原因

1、维护:需要独立维护—棵B+树,用来加速数据查询和排序;考虑数据页的合并和分裂

2、空间:额外的存储空间

3、回表:二级索引不保存完整数据,只保存索引键和主键字段

解决方案

1、按需创建

2、考虑联合索引

3、针对轻量级字段创建

建了索引但是用不上的3种情况

情况1:查询数据内容不走左匹配

情况2:查询字段使用函数运算

情况3:查询没有使用联合索引最左边的列

多个独立索引和联合索引如何选择的问题

考虑:多个字段会在一个条件中查询,并且更有可能走索引覆盖

不考虑:永远只是单—列的查询

相同的SQL语句,有的时候能走索引有的时候不走索引的现象(MySQL optimizer trace)

原因:MySQL根据不同查询方案的成本来决定是否走索引,索引过滤效果不好的时候,可能走全表扫描更划算

解决︰使用EXPLAIN来观察查询是否会走索引,开启optimizertrace来了解具体原因和成本明细

判等问题

什么时候不能使用==进行值判等(-XX:+PrintStringTableStatistic)

基本类型之间

只能通过==判等

引用类型之间

结论:不能通过==判等,需要使用equals方法

原因:==是判断指针相等、判断对象实例是否是同一个,不代表对象内容是否相同

为什么有的时候String使用==判等会奏效?

原因:直接使用双引号声明出来的两个String 对象指向常量池中的相同字符串

工具:使用-XX:+PrintStringTableStatistic查看字符串常量表

包装类型之间

Integer有的时候使用= =判等会奏效?

原因:Integer内部其实做了缓存,默认缓存[-128,127],在这个区间==奏效

实现equals方法可能出现的诸多坑

原因︰考虑性能先进行指针判等、需要对另一方进行判空、确保类型相同的情况下再进行类型强制转换

解决:使用IDE帮我们生成代码

equals和 hashCode没有配对实现的坑

原因:对象存入哈希表的行为不可测

解决∶务必配对实现,使用IDE帮我们生成代码

equals和compareTo实现逻辑不一致的坑

原因:ArrayList.indexOf使用equals判断对象是否相等,而Collections.binarySearch使用compareTo方法来比较对象以实现搜索

解决:对于自定义的类型,如果要实现Comparable,记得equals、hashCode、compareTo三者逻辑一致

Lombok @EqualsAndHashCode可能的两个坑

坑1

原因:Lombok的@EqualsAndHashCode 注解实现equals和hashCode的时候,默认使用类的所有非static、非 transient的字段

解决:使用@EqualsAndHashCode.Exclude 排除一些字段

坑2

原因:Lombok的@EqualsAndHashCode注解实现equals和hashCode的时候,默认不考虑父类

解决︰设置callSuper = true

数值计算

使用double进行浮点数运算的坑

原因:浮点数无法精确存储,计算会损失精度

解决:

1、使用 BigDecimal表示和计算浮点数,且务必使用字符串的构造方法来初始化 BigDecimal

2、如果一定要用 Double来初始化 BigDecimal的话,可以使用BigDecimal valueOf方法

对double 或 float进行舍入格式化的坑

原因:使用 double或foat配合 String. format或DecimalFormat进行格式化舍入,也会有精度问题

解决:还是需要使用 BigDecima,配合 setscale进行舍入

使用equals对 BigDecimal进行判等的坑

原因:使用equals 比较BigDecimal 会同时比较value 和scale,1.0O不等于1,和我们想的不一样

解决︰如果只比较BigDecimal 的value,可以使用compareTo方法

把 BigDecimal 作为 Key加入HashSet的坑

原因:BigDecimal 的equals和 hashCode方法会同时考虑value 和scale,BigDecimal 的值1.0和1,虽然value相同但是scale 不同

解决︰使用TreeSet替换HashSet,或者先使用stripTrailingZeros方法去掉尾部的零

小心数值溢出但是没有任何异常的坑

原因:大数值计算,数值可能默默溢出,没有任何异常解决:

1、使用Math类的addExact、subtractExact 等 xxExact方法进行数值运算,在溢出时能抛出异常

2、使用大数类 BigInteger,需要转到Long 时使用longValueExact,在溢出时能抛出异常

集合类

使用Arrays.asList 把数据转换为List的3个坑

坑1:不能直接使用Arrays.asList来转换基本类型数组

原因:只能是把 int装箱为Integer,不可能把int数组装箱为Integer 数组,int数组整体作为了一个对象成为了泛型类型T解决:使用Arrays.stream 或传入Integer[]

坑2: Arrays.asList返回的List不支持增删操作

原因:Arrays.asList返回的List并不是我们期望的java.util.ArrayList,而是Arrays 的内部类ArrayList

解决:重新new 一个ArrayList 初始化Arrays.asList返回的List

坑3∶对原始数组的修改会影响到我们获得的那个List

原因︰内部 ArrayList其实是直接使用了原始的数组

解决:重新new一个ArrayList初始化Arrays.asList返回的List

使用List.subList进行切片操作居然会导致OOM

原因:List.subList返回的是内部类SubList 会引用原始List,SubList有强引用时会导致原来的 List也无法GC

解决∶

1、不直接使用subList方法返回的SubList,而是使用newArrayList来重新构建一个普通的ArrayList

2、对于Java 8使用Stream的skip和limit API来跳过流中的元素,以及限制流中元素的个数

使用数据结构需要考虑平衡时间和空间(MAT)

时间:要实现快速查询元素,可以考虑使用HashMap替换ArrayList

空间:但是HashMap 数据结构存储利用率相比ArrayList会低很多

工具:使用MAT观察数据结构内存占用

LinkedList适合什么场景呢?

1、在各种常用场景下,LinkedList几乎都不能在性能上胜出ArrayList

2、使用任何数据结构最好根据自己的使用场景来评估和测试,以数据说话

空值处理

注意5种可能出现空指针的情况 (Arthas)

情况1

原因:参数值是Integer 等包装类型,使用时因为自动拆箱出现了空指针异常

解决:对于Integer 的判空,可以使用Optional.ofNullable来构造一个Optional,然后使用orElse(O)把 null替换为默认值再进行操作

情况2

原因:字符串比较出现空指针异常

解决:对于String和字面量的比较,可以把字面量放在前面,比如”OK”.equals(s)

情况3

原因:诸如ConcurrentHashMap这样的容器不支持Key和Value 为null,强行put null的Key 或 Value 会出现空指针异常解决∶不要存null

情况4

原因:A对象包含了B,在通过A对象的字段获得B之后,没有对字段判空就级联调用B的方法会出现空指针异常

解决︰使用Optional.ofNullable 配合map和ifPresent 方法

情况5

原因:方法或远程服务返回的List不是空而是null,没有进行判空就直接调用List的方法,出现空指针异常

解决:使用Optional.ofNullable包装一下返回值,然后通过.orElse(Collections.emptyList()),实现在List为 null的时候获得一个空的List

工具

使用Arthas的 watch命令观察方法入参,定位null参数,使用stack命令观察调用栈定位调用路径

POJO字段设置默认值导致数据库中的原始值被覆盖的坑

原因:POJO中的字段有默认值,如果客户端不传值,就会赋值为默认值,导致每次都把默认值更新到了数据库中

解决:POJO字段不要设置默认值,如果怕没值可以让数据库设置默认值

你见过数据库中出现null字符串的问题吗?

原因:字符串格式化时,可能会把null值格式化为null字符串

解决:使用Optional的 orElse方法一键把空转换为空字符串

客户端不传值以及传null在POJO中都是null,如何区分?

原因:对于JSON到DTO的反序列化过程,null的表达是有歧义的,客户端不传某个属性,或者传 null,这个属性在DTO中都是null

解决︰使用Optional来包装,以区分客户端不传数据还是故意传null

MySQL中涉及NULL的3个容易忽略的坑

坑1

原因:MySQL中sum函数没统计到任何记录时,会返回null而不是0

解决:可以使用IFNULL函数把NULL转换为0

坑2

原因:MySQL中count字段不统计NULL值

解决:可以使用IFNULL函数把NULL转换为О

坑3

原因:MySQL中使用诸如=、<、>这样的算数比较操作符比较NULL的结果总是NULL,这种比较就显得没有任何意义

解决∶对NULL进行判断只能使用IS NULL、IS NOT NULL或者ISNULL()函数

异常处理

 

下载权限
查看
  • 免费下载
    评论并刷新后下载
    登录后下载
  • {{attr.name}}:
您当前的等级为
登录后免费下载登录 小黑屋反思中,不准下载! 评论后刷新页面下载评论 支付以后下载 请先登录 您今天的下载次数(次)用完了,请明天再来 支付积分以后下载立即支付 支付以后下载立即支付 您当前的用户组不允许下载升级会员
您已获得下载权限 您可以每天下载资源次,今日剩余

给TA打赏
共{{data.count}}人
人已打赏
软件编程

告别996,开启Java高效编程之门(完整版)

2022-6-15 14:02:19

软件编程

老男孩带你21周搞定Go语言

2022-6-15 14:45:07

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索