念念不忘，必有回响

进程在申请内存的时候，不是直接分配物理内存，分配一块虚拟空间，等到堆真正使用这块虚拟空间才会发生缺页去分配物理内存。

可以看到增加线程数配置 可以明显减少error错误，即减少。目前是在mac测试数据，预计至少有20%左右的QPS提升其次还有一个可配置参数，默认为cpu核数，最大为4如果cpu核数够多也可以增加该线程数，由于本机线程数有限，增加该线程数性能提升不明显。

大家在自定义 Feign 的编解码器时，如果用到了，应避免的重复初始化。如果不需要使用那些默认的，可以在初始化时将第一个入参设置为 false，从而不初始化那些默认的。另外，应该了解不同的部署方式在类加载器频繁查找和加载资源时是存在性能差异的。我们在写代码时，也应该要避免重复初始化，以及反复查找和加载不存在的资源。

这里真相水落石出了，主要是还是线程池被打满堆积了太多任务导致的如何处理呢增大线程池减少对线程池的请求线程池添加监控broker添加相关的请求限流。

总的来说VisualVM可以为我们统计到一些内存、jvm gc信息。远程接入的方式有两种jmxjstatdjmx需要项目启动的时候添加启动参数，而jstatd不用，但是启动的时候有一个端口是随机的，这样每次可能需要运维帮忙配置打开不同的端口有点麻烦实际线上的环境往往更复杂，VisualVM并不一定能查看到我们排查问题的所有指标。

在 Push 推荐中，线上服务从 Kafka 接收需要触达用户的事件，之后为这些目标用户选出最合适的文章进行推送。服务由 Java 开发，CPU 密集计算型。随着业务的不断发展，请求并发及模型计算量越来越大，导致工程上遇到了性能瓶颈，Kafka 消费出现严重的积压现象，无法及时完成目标用户的分发，业务增长诉求得不到满足，故亟需进行性能专项优化。

文章目录背景System.currentTimeMillis()性能测试单线程测试多线程测试原因优化优化代码单线程测试多线程测试参考背景最近在看asyncTool源码发现了System.currentTimeMillis存在卡顿问题，所以就详细研究了下。具体如何呢？我们来看看System.currentTimeMillis()jdk版本jdk11可以看到该方法被@HotSpotIntrinsicCandidate注解修饰，代表使用HotSpot的实现代替JDK源码的实现方式，即基于CPU指令

作者：颜高飞，微服务领域架构师，主要从事服务发现、高性能网络通信等研发工作，擅长 ZooKeeper、Dubbo、RPC 协议等技术方向。文章目录C10K场景下Dubbo服务调用出现大量交易失败准备环境定制验证场景，观察验证结果C10K场景问题分析观察gc日志、jstack针对场景1：提供方稳定运行过程中交易超时。针对场景2：提供方重启后大量交易超时。场景1：提供方实际交易前后均耗时长、导致交易超时场景2：单边连接导致交易超时分析单边连接影响范围C10K场景问题分析总结下一步思考针对以上场景1针对以上.

说明由于某些原因系统jvm内存最大只能给到512，但是要导出百万数据该如何实现呢？传统的一次性导出肯定是不行的优化Excel导出基于 springboot , easyexcel依赖：<dependency> <groupId>com.alibaba</groupId> <artifactId>easyexcel</artifactId> <version>2.2.6</version>

文章目录下载启动mat生成 dump文件加载dump文件下载启动mat首先我们需要下载启动mat下载mat官网下载地址这里更加自己的系统选择合适的压缩包我选择的是Windows(x86)，下载之后是个zip包，解压就直接可以使用如果分析的dump文件过大需要调整 在 MemoryAnalyzer.ini配置文件中修改 mat的启动参数修改 xmx的启动堆内存即可生成 dump文件这里我们简单的生成一份dump文件运行如下的程序public static void main(

文章目录前言实现核心依赖配置文件实现代码前言尽管我们经过谨慎的评估，仍然不能够保证一次计算出来来的线程池参数是合适的，那么我们是否可以将修改线程池参数的成本降下来，这样至少可以发生故障的时候可以快速调整从而缩短故障恢复的时间呢？基于这个思考，我们是否可以将线程池的参数从代码中迁移到分布式配置中心上，实现线程池参数可动态配置和即时生效，线程池参数动态化前后的参数修改流程对比如下实现分布式配置中心这里使用的是Apollo核心依赖 <dependency> &l

背景在生产使用ClickHouse后，应用是基于Springboot + Mybatis + clickhouse-jdbc + druid去操作ClickHouse。但是写入的瓶颈非常明显，每次数据量超过1W后写入就非常耗时。要几十秒甚至几百秒。按理说ClickHouse的写入性能非常强悍，支持大批量写入，少量数据写入反而很慢，而实际我们在使用Mybatis 写入的性能反而与官方说明有些相反。针对这个写入性能问题我们团队做了几天的排查排查首先排查ClickHouse自身问题我们查询了SQL

流式查询在我们查询大数据量数据，而内存不够的时候，我们常常使用的做法就是分页，分页的效率往往是低下的，当然如果表有自增id主键，基于自增id主键去查询效率也还行，但这不是我们今天介绍的重点，我们今天介绍的重点是Mybatis流式查询，也就是我们在查询数据的时候查询成功后返回的结果集不是一个集合而是一个迭代器，每次从迭代器中处理查询一条结果，这样就能避免大数据导致的OOM。实战MyBatis 流式查询的核心接口是 Cursor可以看到 Cursor 继承了 Iterable接口。由Iterable知

文章目录背景问题排查解决方式总结背景最近需要将任务改为分布式调度，而任务调度使用的是开源的xxl-job改为分布式调度也很简单首先获取当前节点和总节点数量 // 当前分片 int shardIndex = XxlJobHelper.getShardIndex(); // 分片总数 int shardTotal = XxlJobHelper.getShardTotal();获取业务任务取模处理select * from test_j

文章目录背景问题Arthasgithub地址官网文档地址:说明安装运行Arthastrace命令的使用总结背景有时候我们在对线上接口作性能优化的时候需要找出一个方法的代码调用栈具体是那个方法或者哪行代码比较慢最简单的方式就加log // 使用spring提供的计时工具类 StopWatch sw = new StopWatch(); sw.start("调用数据库1"); TimeUnit.SECONDS.sleep(1); sw.st