Java接口优化:dao层慢但是sql快

在接口优化过程中,发现DAO层耗时较长,原来是BeanUtils.copy方法在大量PO到VO转换时效率低下,由于反射机制的影响,性能显著降低。解决方案是使用Lombok的@Builder注解,通过构建者模式提高代码效率和规范性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Java接口优化

场景回顾

当时在优化一个接口,从controller一直查询到dao层,发现dao层时间耗时很长,1.97s,但是dao层只做了一个简单的查询操作。sql时间也很短,只需要几百毫秒,时间到底去了哪里?

查询结果

最后发现,查询sql时间很短,但是返回又很慢,原来是返回的时候使用了BeanUtils.copy()方法,将PO转换为vo,几千个PO速度就会拉慢。

上网查询

测试结果

验证

我用的正是Apache BeanUtils。删除之后,性能果然得到了提升

结论

这种 copy 属性的方法底层都使用了反射,最好不要使用。最简单的方法,还是自己创建类,并赋值属性值。
并且直接使用全参构造器,也不符合规范。
最好方式是

  1. 无参构造器 + set 属性方法
  2. 使用Lombok 的 @Builder 注解,使用builder创建类

文中引用链接

链接: 几种copyProperties工具类性能比较

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值