应用层面
- 反射操作记得缓存method和field，最好能用方法句柄或者字节码增强替换掉
public class PerformanceOptimizationDemo {
private static final Method METHOD;
static {
METHOD = "获取method";
}
}
更多细节见 Java反射性能详解
- 原生String的split和replaceAll请谨慎使用，StringTokenizer是个更好的选择，或者这里推荐org.apache.commons.lang3.StringUtils#replace(String, String, String)这个工具类
- 慎用String.intern，当字符串数量非常多时使用hashmap做缓存性能要好得多
- 放弃Random随机数请用ThreadLocalRandom
public static int getRandomNum() {
// 性能略差
return new Random().nextInt();
// 性能更好的平替
return ThreadLocalRandom.current().nextInt();
}
- 正确应用单例模式，逻辑类尽量使用单例，需注意处理线程安全问题，这里推荐静态工厂方式，其唯一的问题是较多的冗余代码，可使用插件解决
public class PerformanceOptimizationDemo {
private PerformanceOptimizationDemo(){
}
private static class LazyHolder {
private static final PerformanceOptimizationDemo INSTANCE = new PerformanceOptimizationDemo();
}
protected static PerformanceOptimizationDemo getInstance() {
return PerformanceOptimizationDemo.LazyHolder.INSTANCE;
}
}
- 使用三方库如果是实例级的方法而非static的使用方法，查看api查看实例是否线程安全，线程安全时创建一个单例实例，而非在方法中每次都创建一个实例如ObjectMapper，此外对应各种Factory和Context要更严格地检查，频繁地创建Factory和Context可能会对内存造成较大的压力甚至导致Fullgc
private static final ObjectMapper DEFAULT_OBJECT_MAPPER = getObjectMapper();
- 递归调用层次比较深时但可以预见栈底时优化为循环（相当于手动实现尾递归转为循环）
- 合理使用多级缓存, 本地缓存->远程缓存(redis、etcd) ，做缓存时考虑好超时时间、淘汰策略、容量规划、最终一致性，这里推荐jetcache
@Override
@Cached(name = "user.", key = "#id", expire = 3600, cacheType = CacheType.REMOTE, postCondition = "result != null")
public UserInfo getData(Long id) {
return Optional.ofNullable(userMapper.selectById(id))
.map(user -> convert(user, UserInfo.class))
.orElse(null);
}
- 接上一条，业务配置数据在初始化时直接加载到缓存和内存，优先从内存和缓存读取，没有再去读数据库并加载到内存和缓存中
- Mq消息批处理
- 数据库批处理(尽量不要在for循环里面进行数据库操作)，注意jdbc参数rewriteBatchedStatements和allowMultiQueries要为true
private final UserMapper userMapper;
public void batchInsert(List<UserDo> userList) {
// 此种操作会占用较多的数据库连接且多次访问数据库rt会慢很多
userList.forEach(user -> userMapper.insert(user));
}
- 数据库部分场景下有事务比没有事务要执行的更快，比如一些查询虽然是本身是无事务性的，但是多个小的查询放在一个事务中有利于复用连接避免了从连接池中获取连接的开销(没有连接池的话这个应用是存在一定问题的)
@Transactional(readOnly = true)
public void doSomething() {
doQuery0();
doQuery1();
doQuery2();
}
- 巨型对象使用完手动赋值null（请一定确认是个巨型对象也不会再次复用）
- 业务允许的情况下使用cas+重试替换悲观锁
- 涉及大文件操作，使用nio技术优化写入(小文件可能适得其反)，简单示例：
public static void writeToFile(String filePath, String content) throws IOException {
try (FileOutputStream fos = new FileOutputStream(filePath);
FileChannel channel = fos.getChannel()) {
// 将内容转换为字节数组
byte[] bytes = content.getBytes();
// 创建ByteBuffer
ByteBuffer buffer = ByteBuffer.allocate(bytes.length);
buffer.put(bytes);
// 将Buffer切换为读取模式
buffer.flip();
// 将数据写入到文件通道
while (buffer.hasRemaining()) {
channel.write(buffer);
}
}
}
- 开启多线程多个独立任务并发进行(谨慎使用, 多线程调试困难且使用不当会引发全局性的问题)，一般而言多线程主要是实现rt的降低并不会实现资源利用率的提升
- 接上一条线程应当在线程池中运行，顺便贴一些使用线程池的注意点：
-
线程池使用的注意点
- ThreadLocal(登录信息上下文或其它的业务信息)丢失；
- 合适的任务队列及其大小，过大会造成 oom ；
- 全链路 id 丢失；
- 合适的线程池策略和线程数(固定数目和不定数目)；
- 任务重启丢失(优雅退出)；
- 大循环里面可以使用Thread.sleep(0) 让线程重新竞争，可以更充分的利用cpu资源(上下文切换也有开销)，native方法执行以后就会插入一个safepoint，可以帮助gc
- 尝试r2dbc这种异步数据库连接框架(谨慎，需搭配一整套异步框架使用)
- 日志异步化, 异步输出日志不阻塞业务线程，资源允许的情况下引入类似kafka+ elk的日志系统，把日志的开销直接抽离业务系统
- 数据库连接预热，缓存预热及其它可预热的资源，在预热和资源空闲率之间做权衡
- 连接数和线程数调整(数据库连接池、redis连接池、http连接池、tomcat线程数配置, dubbo处理线程数配置)等
- 使用aop切面功能时将aspectj相关jar包版本升级到1.9.0及以上，如果是根据注解切面RetentionPolicy应设置为RUNTIME
数据库层面
- 合理设计表结构：冗余等要适当，要对数据量做合理的评估
-
分库分表：需考虑分库事务、读扩散等问题，对原有的join方式可能不兼容
- 分库分表方式
- 客户端分表
- 使用数据库代理层
- 使用分布式数据库
- 分库分表策略
- 按分片键水平分
- 按时间（年/月/周/日）分
- 其它自定义策略
- 分库分表方式
- 合理加索引：是否有足够区分度？联合索引还是独立索引？是否唯一？索引容量。
- 索引性能和预期时刻想差较大时刻重建索引（该项慎重，小心锁表时间过长影响业务）
- 定期优化表消除空间碎片，可考虑业务低谷期重做一些表（需考虑表的大小预估时间），最好配合合理的数据归档
机器层面
- redis绑核
- jvm参数调优（该项做不好就是反向优化需慎重）
- 内核参数调整（文件打开数、线程限制、页大小等需慎重）
网络层面
- cdn优化寻址
- nginx配置优化（工作线程数等，nginx是一个多进程架构）
- tcp参数调优
性能优化没有银弹，所有的优化要以业务的诉求和业务量为基石，实践是检验真理的唯一标准。
原文地址：https://pebble-skateboard-d46.notion.site/Java-9e8e05c6bdcf4b64a24a9697d74e48ab?pvs=74
