
Java日常开发的21个坑,你踩过几个?
前言
最近看了极客时间的《Java业务开发常见错误100例》,再结合平时踩的一些代码坑,写写总结,希望对大家有帮助,感谢阅读~
1. 六类典型空指针问题
- 包装类型的空指针问题
- 级联调用的空指针问题
- Equals方法左边的空指针问题
- ConcurrentHashMap 这样的容器不支持 Key 和 Value 为 null。
- 集合,数组直接获取元素
- 对象直接获取属性
1.1包装类型的空指针问题
1.2 级联调用的空指针问题
1.3 Equals方法左边的空指针问题
1.4 ConcurrentHashMap 这样的容器不支持 Key,Value 为 null。
1.5 集合,数组直接获取元素
1.6 对象直接获取属性
2. 日期YYYY格式设置的坑
日常开发,经常需要对日期格式化,但是呢,年份设置为YYYY大写的时候,是有坑的哦。
反例:
运行结果:
「解析:」
为什么明明是2019年12月31号,就转了一下格式,就变成了2020年12月31号了?因为YYYY是基于周来计算年的,它指向当天所在周属于的年份,一周从周日开始算起,周六结束,只要本周跨年,那么这一周就算下一年的了。正确姿势是使用yyyy格式。
正例:
3.金额数值计算精度的坑
看下这个浮点数计算的例子吧:
运行结果:
可以发现,结算结果跟我们预期不一致,其实是因为计算机是以二进制存储数值的,对于浮点数也是。对于计算机而言,0.1无法精确表达,这就是为什么浮点数会导致精确度缺失的。因此,「金额计算,一般都是用BigDecimal 类型」
对于以上例子,我们改为BigDecimal,再看看运行效果:
运行结果:
发现结果还是不对,「其实」,使用 BigDecimal 表示和计算浮点数,必须使用「字符串的构造方法」来初始化 BigDecimal,正例如下:
在进行金额计算,使用BigDecimal的时候,我们还需要「注意BigDecimal的几位小数点,还有它的八种舍入模式哈」。
4. FileReader默认编码导致乱码问题
看下这个例子:
运行结果:
从运行结果,可以知道,系统默认编码是utf8,demo中读取出来,出现乱码了。为什么呢?
❝
FileReader 是以当「前机器的默认字符集」来读取文件的,如果希望指定字符集的话,需要直接使用 InputStreamReader 和 FileInputStream。
❞
正例如下:
5. Integer缓存的坑
运行结果:
为什么Integer值如果是128就不相等了呢?「编译器会把 Integer a = 127 转换为 Integer.valueOf(127)。」 我们看下源码。
可以发现,i在一定范围内,是会返回缓存的。
❝
默认情况下呢,这个缓存区间就是[-128, 127],所以我们业务日常开发中,如果涉及Integer值的比较,需要注意这个坑哈。还有呢,设置 JVM 参数加上 -XX:AutoBoxCacheMax=1000,是可以调整这个区间参数的,大家可以自己试一下哈
❞
6. static静态变量依赖spring实例化变量,可能导致初始化出错
之前看到过类似的代码。静态变量依赖于spring容器的bean。
这个静态的smsService有可能获取不到的,因为类加载顺序不是确定的,正确的写法可以这样,如下:
7. 使用ThreadLocal,线程重用导致信息错乱的坑
使用ThreadLocal缓存信息,有可能出现信息错乱的情况。看下下面这个例子吧。
按理说,每次获取的before应该都是null,但是呢,程序运行在 Tomcat 中,执行程序的线程是 Tomcat 的工作线程,而 Tomcat 的工作线程是基于线程池的。
❝
线程池会重用固定的几个线程,一旦线程重用,那么很可能首次从 ThreadLocal 获取的值是之前其他用户的请求遗留的值。这时,ThreadLocal 中的用户信息就是其他用户的信息。
❞
把tomcat的工作线程设置为1
用户1,请求过来,会有以下结果,符合预期:
用户2请求过来,会有以下结果,「不符合预期」:
因此,使用类似 ThreadLocal 工具来存放一些数据时,需要特别注意在代码运行完后,显式地去清空设置的数据,正例如下:
8. 疏忽switch的return和break
这一点严格来说,应该不算坑,但是呢,大家写代码的时候,有些朋友容易疏忽了。直接看例子吧
输出结果:
switch 是会「沿着case一直往下匹配的,知道遇到return或者break。」 所以,在写代码的时候留意一下,是不是你要的结果。
9. Arrays.asList的几个坑
9.1 基本类型不能作为 Arrays.asList方法的参数,否则会被当做一个参数。
运行结果:
Arrays.asList源码如下:
9.2 Arrays.asList 返回的 List 不支持增删操作。
运行结果:
Arrays.asList 返回的 List 并不是我们期望的 java.util.ArrayList,而是 Arrays 的内部类 ArrayList。内部类的ArrayList没有实现add方法,而是父类的add方法的实现,是会抛出异常的呢。
9.3 使用Arrays.asLis的时候,对原始数组的修改会影响到我们获得的那个List
运行结果:
从运行结果可以看到,原数组改变,Arrays.asList转化来的list也跟着改变啦,大家使用的时候要注意一下哦,可以用new ArrayList(Arrays.asList(arr))包一下的。
10. ArrayList.toArray() 强转的坑
因为返回的是Object类型,Object类型数组强转String数组,会发生ClassCastException。解决方案是,使用toArray()重载方法toArray(T[] a)
11. 异常使用的几个坑
11.1 不要弄丢了你的堆栈异常信息
正确的打印方式,应该酱紫
11.2 不要把异常定义为静态变量
exceptionTwo抛出的异常,很可能是 exceptionOne的异常哦。正确使用方法,应该是new 一个出来。
11.3 生产环境不要使用e.printStackTrace();
因为它占用太多内存,造成锁死,并且,日志交错混合,也不易读。正确使用如下:
11.4 线程池提交过程中,出现异常怎么办?
运行结果:
可以发现,如果是使用submit方法提交到线程池的异步任务,异常会被吞掉的,所以在日常发现中,如果会有可预见的异常,可以采取这几种方案处理:
- 1.在任务代码try/catch捕获异常
- 2.通过Future对象的get方法接收抛出的异常,再处理
- 3.为工作者线程设置UncaughtExceptionHandler,在uncaughtException方法中处理异常
- 4.重写ThreadPoolExecutor的afterExecute方法,处理传递的异常引用
11.5 finally重新抛出的异常也要注意啦
一个方法是不会出现两个异常的呢,所以finally的异常会把try的「异常覆盖」。正确的使用方式应该是,finally 代码块「负责自己的异常捕获和处理」。
12.JSON序列化,Long类型被转成Integer类型!
「运行结果:」
❝
「注意啦」,序列化为Json串后,Josn串是没有Long类型呢。而且反序列化回来如果也是Object接收,数字小于Interger最大值的话,给转成Integer啦!
❞
13. 使用Executors声明线程池,newFixedThreadPool的OOM问题
「IDE指定JVM参数:-Xmx8m -Xms8m :」
运行结果:
我们看下源码,其实newFixedThreadPool使用的是无界队列!
❝
newFixedThreadPool线程池的核心线程数是固定的,它使用了近乎于无界的LinkedBlockingQueue阻塞队列。当核心线程用完后,任务会入队到阻塞队列,如果任务执行的时间比较长,没有释放,会导致越来越多的任务堆积到阻塞队列,最后导致机器的内存使用不停的飙升,造成JVM OOM。
❞
14. 直接大文件或者一次性从数据库读取太多数据到内存,可能导致OOM问题
如果一次性把大文件或者数据库太多数据达到内存,是会导致OOM的。所以,为什么查询DB数据库,一般都建议分批。
读取文件的话,一般问文件不会太大,才使用Files.readAllLines()
。为什么呢?因为它是直接把文件都读到内存的,预估下不会OOM才使用这个吧,可以看下它的源码:
如果是太大的文件,可以使用Files.line()按需读取,当时读取文件这些,一般是使用完需要「关闭资源流」的哈
15. 先查询,再更新/删除的并发一致性问题
再日常开发中,这种代码实现经常可见:先查询是否有剩余可用的票,再去更新票余量。
如果是并发执行,很可能有问题的,应该利用数据库的更新/删除的原子性,正解如下:
16. 数据库使用utf-8存储, 插入表情异常的坑
低版本的MySQL支持的utf8编码,最大字符长度为 3 字节,但是呢,存储表情需要4个字节,因此如果用utf8存储表情的话,会报SQLException: Incorrect string value: '\xF0\x9F\x98\x84' for column
,所以一般用utf8mb4编码去存储表情。
17. 事务未生效的坑
日常业务开发中,我们经常跟事务打交道,「事务失效」主要有以下几个场景:
- 底层数据库引擎不支持事务
- 在非public修饰的方法使用
- rollbackFor属性设置错误
- 本类方法直接调用
- 异常被try...catch吃了,导致事务失效。
其中,最容易踩的坑就是后面两个,「注解的事务方法给本类方法直接调用」,伪代码如下:
如果异常被catch住,「那事务也是会失效呢」~,伪代码如下:
18. 当反射遇到方法重载的坑
运行结果:
如果「不通过反射」,传入Integer.valueOf(100)
,走的是Integer重载。但是呢,反射不是根据入参类型确定方法重载的,而是「以反射获取方法时传入的方法名称和参数类型来确定」的
19. mysql 时间 timestamp的坑
有更新语句的时候,timestamp可能会自动更新为当前时间,看个demo
我们可以发现 「c列」 是有CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
,所以c列会随着记录更新而「更新为当前时间」。但是b列也会随着有记录更新为而「更新为当前时间」。
可以使用datetime代替它,需要更新为当前时间,就把now()
赋值进来,或者修改mysql的这个参数explicit_defaults_for_timestamp
。
20. mysql8数据库的时区坑
之前我们对mysql数据库进行升级,新版本为8.0.12。但是升级完之后,发现now()函数,获取到的时间比北京时间晚8小时,原来是因为mysql8默认为美国那边的时间,需要指定下时区
参考与感谢
[1]Java业务开发常见错误100例:https://time.geekbang.org/column/article/220230
文章转载自公众号:捡田螺的小男孩
