最近在做 Java Agent 的相关开发,参考部分开源代码实现的自定义类加载器实现时,部分类加载器实现含有以下静态块:
1 | static { |
最近在做 Java Agent 的相关开发,参考部分开源代码实现的自定义类加载器实现时,部分类加载器实现含有以下静态块:
1 | static { |
在我之前的工程中,使用 EMR-OSS 将 阿里云对象存储 OSS 与 Spark 集群进行了整合,采用 OSS 作为存储实现,在一次性能问题排查过程中,发现 EMR-OSS 连接器的代码中有对 System.gc()
的显式调用,该调用导致频繁 FullGC,在修复前我先使用 JVM 参数 -XX:+DisableExplicitGC
规避了频繁 FullGC 的问题,后提交了 PR 对该问题进行修复。
注:设置 -XX:+DisableExplicitGC
可能影响直接内存回收,使用该选项须谨慎。
Remove explicit calls to System.gc() #369
GCeasy
Impact of setting -XX:+DisableExplicitGC when NIO direct buffers are used - Stack Overflow
该问题我在 2020 年 02 月 04 日排查线上 Redis 性能抖动时发现,当时 spring-data-redis 的 @Cacheable 对 allEntries = true 的实现机制仅有 keys 命令一种,当时我仅将项目中 allEntries = true 调整为指定 key 的方式绕开了对 keys 命令的调用,最近看到 spring-data-redis 已经新增了对 SCAN 命令的支持。
如果查看 Redis 官网中对 KEYS pattern 命令的介绍就能知道,该命令时间复杂度为 O(N),并且在警告中提到,应谨慎在生产环境中使用,若在大型数据库上执行该命令,可能导致糟糕的性能,此命令应用于调试或其他指定的操作,不要在常规的应用程序代码中使用 KEYS 命令,如果你在寻找一种在整个键空间中查询键的子集的方式,请考虑使用 SCAN 或 sets 命令。
在 2020 年 05 月 21 日有人在 GitHub 提出了关于该问题的 issue: DefaultRedisCacheWriter.clean() uses blocking KEYS command [DATAREDIS-1151] #1721
基于 SCAN 命令的实现在 2021 年 04 月 21 日被提交,参考:Add support for configurable batch strategies using RedisCache.
在Thread
类的源码中,可以看到以下声明:
1 | public |
可以看出,Thread
的实例持有了对 ThreadLocal.ThreadLocalMap
实例 threadLocals
的引用。
在 Tomcat 的官方配置文档 Apache Tomcat 8 Configuration Reference 中,其中对 maxPostSize
的描述如下:
The maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value less than zero. If not specified, this attribute is set to 2097152 (2 megabytes). Note that the FailedRequestFilter can be used to reject requests that exceed this limit.