关于日志打印以及Spring事务控制的日常坑坑洼洼

最近在重新整理老系统的业务,基于老平台开发新的业务。看到一段关于财务退款的处理,很开心,这不就是我一直在找的核心处理模块吗。看一下出入参以及大致逻辑,决定复用。三下除以两下,调用业务,打印日志,OK,测试。然而,测试一跑,便是相当尴尬,而且越跑越尴[/强颜欢笑]
先是日志一段刷没有看到异常堆栈,退款单据也成功了,但是快递费用没有退,即退款明细没处理完,单据成功了。WTF,这不是事务没回滚吗,可是没异常呀,是不是异常被吃掉(捕捉)或者被什么条件过滤掉了。review了一下代码,发现:增强for循环里面更新集合数据,那么该出场的 java.util.ConcurrentModificationException堆栈呢?捕捉异常看了一下,是:e.getMessage()......诶,grep搜索一下日志,真心有一行日志是这个异常,但是不好发现,日志的打印还需要规范引发思考......
一、关于Exception日志打印心得,总结记录收集一下:
(1)打印日志堆栈要清晰:打印日志要打印出异常堆栈,尽量避免e.getMessage()打印,业务可处理异常除外。
(2)注意吃掉异常事务不会滚:异常导致的需要回滚事务要记得抛出异常,不要吃掉异常导致事务不会滚。
(3)该细化异常类型时细化,避免泛化:此做法在于支持不同的处理和恢复措施,业务异常和其他费业务运行时异常区分开,易于代码调试。这个细化要注意子类异常的处理块必须在父类异常处理块的前面,否则会发生编译错误。
(4)延迟捕捉异常:如果本段代码还没有能力处理异常,尽管抛出让调用方决定,目的在于准确处理。但也要注意避免异常转化过程丢失信息。
(5)异常处理框架:对于一个应用系统来说,有自己的一套异常处理框架,当异常发生时,就能得到统一的处理风格,将优雅的异常信息反馈给用户。
(6)用Json、Gson的打印时避免出现堆溢出java.lang.*Error:主要@manyToOne和@oneToMany的注解,主子级联,打印时相互寻找引起死循环,从而出现不该出现的打印异常,屏蔽了该关注的异常。
关于日志打印以及Spring事务控制的日常坑坑洼洼
二、其次,就是上面提到的关于java.util.ConcurrentModificationException异常:使用增强 for 循环(这个语法糖解糖的结果其实迭代器遍历)遍历元素,并尝试删除增加其中的元素会触发fail-fast机制,即快速失败,它是 Java 集合的一种错误检测机制。当多个线程对集合(非fail-safe 的集合类)进行结构上的改变的并发操作时,有可能会产生 fail-fast 机制,这个时候就会抛出ConcurrentModificationException(当方法检测到对象的并发修改,但不允许这种修改时就抛出该异常)。同时需要注意的是,即使不是多线程环境,如果单线程违反了规则,同样也有可能会抛出改异常。把出现这个异常的代码改成普通循环即不会触发这个错误检测机制,但是要注意不要漏处理元素,因为删除下标的改动。
三、最后补一下关于事务不生效的日常发现:
(1)吃掉异常:没有异常事务当然不生效。
(2)事务方法私有private也会导致事务不生效,这应该时切面AOP定义的限制。
(3)同一个类中, 一个nan-transactional的方法去调用transactional的方法, 事务也不会效:spring是采用动态代理机制来实现事务@Transactional控制,而动态代理最终都是要调用原始对象即调用方的,而原始对象(没有携带事务信息)在去调用方法时,是不会再触发事务的。所以一个没有事务的方法去调用有事务的方法,事务也不会生效,重点在于源对象有无事务信息。
解决①把事务方法抽取出去另外一个服务类,通过注入给调用方调用。
解决②调用方获取代理对象去调用事务方法,避免用源对象去直接调用:声明一下,以下截图来源:https://blog.csdn.net/m0_38027656/article/details/84190949
关于日志打印以及Spring事务控制的日常坑坑洼洼

上一篇:vue项目打包部署后页面是空白的,以及部署之后页面能看到图片等资源找不到


下一篇:gradle命令行的基本使用