性能文章>【全网首发】不经意的两行代码把CPU使用率干到了90%+>

【全网首发】不经意的两行代码把CPU使用率干到了90%+原创

7845810

背景介绍

某同学反映某个应用ECS CPU使用率90%+,希望分析下原因。
该应用使用schedulerx来做定时任务执行,每隔一小时执行一次,每次执行5分钟左右,执行任务期间CPU使用率90%+。

问题现象

image.png
ECS配置是4c8g,从上图来看系统负载已经非常高了。

分析过程

寻找热点代码

arthas profiler比较适用CPU使用率持续较高的场景。通过对热点火焰图的分析,NoSuchMethodException异常相关代码占用了很多CPU时间。
11.png
上图红框中NoSuchMethodException展开后如下图:
21.png

分析异常

ClassUtils

从上图可以看出org.springframework.util.ClassUtils.getStaticMethod调用了Class.getMethod,Class.getMethod抛出了NoSuchMethodException,代码如下。
image.png
为了进一步定位问题,需要知道ClassUtils.getStaticMethod方法的入参:
image.png
从上图看出ClassUtils.getStaticMethod方法入参分别是:
**clazz:java.util.Date;_methodName:_valueOf;args[0]:**java.sql.Timestamp。上面图片只是截取了一部分,其中methodName还有of、from。

ObjectToObjectConverter

调用ClassUtils.getStaticMethod的地方是org.springframework.core.convert.support.ObjectToObjectConverter.determineFactoryMethod:
image.png
调用ObjectToObjectConverter.determineFactoryMethod的地方是ObjectToObjectConverter.getValidateMember:
image.png
虽然java.sql.Timestamp是java.util.Date的子类,但是从上面代码可以看出进行了很多次无效的调用。

定位业务代码

定位业务代码

为了更准确的定位相关业务代码,我们需要知道抛出NoSuchMethodException的线程栈,可以使用arthas stack,从线程栈我们可以知道在【哪个类哪个方法哪行】发出的调用。

stack org.springframework.util.ClassUtils getStaticMethod 'returnObj==null'

311.png

分析业务代码

在我们没有源代码的情况,我们可以使用arthas jad反编译定位到的类,进而分析业务代码,到这里就可以具体定位到问题了。
41.png
gmt_created、gmt_modified在实体类中的定义:
61.png

异常场景回顾

  1. 查询数据库,数据库返回ResultSet对象
  2. 遍历ResultSet,将ResultSet每一行映射到相应的业务实体类
    1. 实例化业务实体类,根据ResultSet.getMetaData()获取每一列的值并将该值set到实体类对应属性上
      1. 在将gmt_created、gmt_modified解析为java.sql.Timestamp类实例,接着使用ObjectToObjectConverter将java.sql.Timestamp转换为java.util.Date的时候抛出了NoSuchMethodException

异常场景复现示例代码

import com.alibaba.druid.pool.DruidDataSource;
import org.springframework.jdbc.core.BeanPropertyRowMapper;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;

import java.util.List;
public class TimestampToDateTest {
    public static void main(String[] args){
        DruidDataSource dataSource = new DruidDataSource();
        dataSource.setUrl("jdbc:mysql://localhost/world?useSSL=false&serverTimezone=UTC");
        dataSource.setUsername("root");
        dataSource.setPassword("");
        dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
		
        JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);
        String sql = "select now() as gmt_created,now() as gmt_modified";
		RowMapper rowMapper = new BeanPropertyRowMapper(TimestampToDate.class);
        List<TimestampToDate> list = jdbcTemplate.query(sql,rowMapper);
        for(TimestampToDate timestampToDate : list){
            System.out.println(timestampToDate.getGmtCreated().getClass().getName());
        }
    }
}
import java.util.Date;
public class TimestampToDate {
    private Date gmtCreated;
    private Date gmtModified;

    public Date getGmtCreated() {
        return gmtCreated;
    }
    public void setGmtCreated(Date gmtCreated) {
        this.gmtCreated = gmtCreated;
    }
    public Date getGmtModified() {
        return gmtModified;
    }
    public void setGmtModified(Date gmtModified) {
        this.gmtModified = gmtModified;
    }
}

解决办法

数据库表中gmt_created、gmt_modified类型与实体类中对应字段类型的定义保持一致,可以解决异常。

延申阅读

通过提高BeanPropertyRowMapper相关逻辑的缓存命中率可以进一步优化性能,如提前将转换逻辑放到GenericConversionService类的converters中:

BeanPropertyRowMapper rowMapper = new BeanPropertyRowMapper(TimestampToDate.class);
DefaultConversionService conversionService = (DefaultConversionService)rowMapper.getConversionService();
conversionService.addConverter(Timestamp.class, Date.class, new Converter<Timestamp, Date>() {
	@Override
	public Date convert(Timestamp source) {
		return source;
	}
});

另外可以通过自定义RowMapper来提高性能,因为BeanPropertyRowMapper并不是高性能的一种实现:
image.png

参考资料

Java, JDBC, and MySQL Types

点赞收藏
大禹的足迹

在阿里搬了几年砖的大龄码农,头条号:大禹的足迹

请先登录,查看8条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

一次 Rancher go 应用内存占用过高问题排查

一次 Rancher go 应用内存占用过高问题排查

实现定时任务的六种策略

实现定时任务的六种策略

10
8