hashcon-CSDN博客

原创全网最硬核 JVM 内存解析 - 1.从 Native Memory Tracking 说起

网上有很多关于 JVM 内存结构的分析以及图片，但是由于不是一手的资料亦或是人云亦云导致有很错误，造成了很多误解；并且，这里可能最容易混淆的是一边是 JVM Specification 的定义，一边是 Hotspot JVM 的实际实现，有时候人们一些部分说的是 JVM Specification，一部分说的是 Hotspot 实现，给人一种割裂感与误解。本篇主要从 Hotspot 实现出发，以 Linux x86 环境为主，紧密贴合 JVM 源码并且辅以各种 JVM 工具验证帮助大家理解 JVM 内存的结

2023-04-26 06:41:23 952

原创全网最硬核 Java 新内存模型解析与实验单篇版（不断更新QA中）

本篇文章参考了大量文章，文档以及论文，但是这块东西真的很繁杂，我的水平有限，可能理解的也不到位，如有异议欢迎留言提出。本系列会不断更新，结合大家的问题以及这里的错误和疏漏，欢迎大家留言

2022-03-30 20:44:44 1774 3

原创一次鞭辟入里的 Log4j2 异步日志输出阻塞问题的定位

一次鞭辟入里的 Log4j2 日志输出阻塞问题的定位问题现象线上某个应用的某个实例突然出现某些次请求服务响应极慢的情况，有几次请求超过 60s 才返回，并且通过日志发现，服务线程并没有做什么很重的操作。这种情况断断续续持续了半小时左右。核心问题定位由于半小时后，服务实例恢复正常，并且出现请求极慢的次数并不太多，没有能及时打印出现问题的时候线程堆栈采集相关信息。但是，我们有自己的法宝，JFR（关于 JFR，请参考我的另一系列JFR全解）。JFR 非常适合用来事后复盘定位问题，并且配置得当的话，性能损

2021-07-06 09:10:57 1758 1

原创一次 RocketMQ 顺序消费延迟的问题定位

一次 RocketMQ 顺序消费延迟的问题定位问题背景与现象昨晚收到了应用报警，发现线上某个业务消费消息延迟了 54s 多（从消息发送到MQ 到被消费的间隔）：2021-06-30T23:12:46.756 message processing is incredibly delayed! (Current delay time: 54725, incredible delay count in 10 seconds: 5677) 查看 RocketMQ 的监控，发现确实发生了比较多的消息积压：

2021-07-01 19:04:45 876

原创 SpringCloud 升级之路-2020.0.x-7.使用 Spring Cloud LoadBalancer (2)

本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford我们使用 Spring Cloud 官方推荐的 Spring Cloud LoadBalancer 作为我们的客户端负载均衡器。上一节我们了解了 Spring Cloud LoadBalancer 的结构，接下来我们来说一下我们在使用 Spring Cloud LoadBalancer 要实现的功能：我们要实现不同集群之.

2021-05-29 13:34:00 803

原创 SpringCloud升级之路-2020.0.x - 6.使用 Spring Cloud LoadBalancer(1)

本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford我们使用 Spring Cloud 官方推荐的 Spring Cloud LoadBalancer 作为我们的客户端负载均衡器。Spring Cloud LoadBalancer背景Spring Cloud LoadBalancer是一个客户端负载均衡器，类似于Ribbon，但是由于Ribbon已经进入维护模式，并且Ri.

2021-05-28 17:41:54 1344

原创 Spring Cloud 升级之路 - 2020.0.x - 5. 理解 NamedContextFactory

spring-cloud-commons 中参考了 spring-cloud-netflix 的设计，引入了 NamedContextFactory 机制，一般用于对于不同微服务的客户端模块使用不同的子 ApplicationContext 进行配置。spring-cloud-commons 是 Spring Cloud 对于微服务基础组件的抽象。在一个微服务中，调用微服务 A 与调用微服务 B 的配置可能不同。比较简单的例子就是，A 微服务是一个简单的用户订单查询服务，接口返回速度很快，B 是一个报表

2021-05-26 10:14:15 377 1

原创 Spring Cloud 升级之路 - 2020.0.x - 4. 使用 Eureka 作为注册中心

Eureka 目前的状态：Eureka 目前 1.x 版本还在更新，但是应该不会更新新的功能了，只是对现有功能进行维护，升级并兼容所需的依赖。 Eureka 2.x 已经胎死腹中了。但是，这也不代表 Eureka 就是不能用了。如果你需要一个简便易于部署的注册中心，Eureka 还是一个很好的选择。云服务环境中，基本上所有实例地址和微服务名称都在不断变化，也并不太需要 Eureka 所缺少的持久化特性。当你的集群属于中小规模的时候（节点小于 1000 个）， Eureka 依然是一个不错的选择。当你的集群很

2021-05-10 18:26:11 315

原创 Spring Cloud 升级之路 - 2020.0.x - 3. Undertow 的 accesslog 配置

上一节我们讲述了如何使用 Undertow 作为我们的 Web 服务容器，本小节我们来分析使用 Undertow 的另一个问题，也就是如何配置 accesslog，以及 accesslog 的各种占位符。accesslog 相关配置server: undertow: # access log相关配置 accesslog: # 存放目录，默认为 logs dir: ./log # 是否开启 enabled: true # 格式

2021-04-08 00:20:00 13205

原创 Spring Cloud 升级之路 - 2020.0.x - 2. 使用 Undertow 作为我们的 Web 服务容器

本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford在我们的项目中，我们没有采用默认的 Tomcat 容器，而是使用了 UnderTow 作为我们的容器。其实性能上的差异并没有那么明显，但是使用 UnderTow 我们可以利用直接内存作为网络传输的 buffer，减少业务的 GC，优化业务的表现。Undertow 的官网：https://undertow.io/但是，Un.

2021-04-06 21:36:11 13940 1

原创 Spring Cloud 升级之路 - 2020.0.x - 1. 背景知识、需求描述与公共依赖

1. 背景知识、需求描述与公共依赖1.1. 背景知识 & 需求描述Spring Cloud 官方文档说了，它是一个完整的微服务体系，用户可以通过使用 Spring Cloud 快速搭建一个自己的微服务系统。那么 Spring Cloud 究竟是如何使用的呢？他到底有哪些组件？spring-cloud-commons组件里面，就有 Spring Cloud 默认提供的所有组件功能的抽象接口，有的还有默认实现。目前的 2020.0.x （按照之前的命名规则应该是 iiford），也就是spring

2021-04-04 08:32:27 13426

原创全网最硬核 JVM TLAB 分析(额外加菜) 8. 通过 JFR 监控 TLAB

今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）全网最硬核 JVM TLAB 分析 1. 内存分配思想引入全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析.

2021-02-04 10:14:45 44069

原创全网最硬核 JVM TLAB 分析 6. TLAB 相关热门Q&A汇总

今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）全网最硬核 JVM TLAB 分析 1. 内存分配思想引入全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析.

2021-02-04 10:11:59 43567

原创全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析

今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）全网最硬核 JVM TLAB 分析 1. 内存分配思想引入全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析.

2021-02-04 10:10:41 44502

原创全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）

今天，又是干货满满的一天。这是全网最硬核 JVM 系列的开篇，首先从 TLAB 开始。由于文章很长，每个人阅读习惯不同，所以特此拆成单篇版和多篇版全网最硬核 JVM TLAB 分析（单篇版不包含额外加菜）全网最硬核 JVM TLAB 分析 1. 内存分配思想引入全网最硬核 JVM TLAB 分析 2. TLAB生命周期与带来的问题思考全网最硬核 JVM TLAB 分析 3. JVM EMA期望算法与TLAB相关JVM启动参数全网最硬核 JVM TLAB 分析 4. TLAB 基本流程全分析.

2021-02-04 10:08:11 44806

原创 Spring Cloud系列之Commons - 2. 服务发现 - 如何通过配置文件配置服务实例？

Spring Cloud Commons 主要包括如下模块的接口和默认实现：其中的限流策略以及重试策略是没有天然带的，但是其他模块的实现一般会带上这些功能。我们先从服务发现相关接口开始分析服务发现相关核心接口DiscoveryClientDiscoveryClientpublic interface DiscoveryClient extends Ordered { int DEFAULT_ORDER = 0; //描述 String description(); //通过

2021-01-27 08:58:49 17683

原创 Spring Cloud系列之Commons - 1. 背景与基础知识准备

本文基于 Spring Cloud 2020.0 发布版的依赖本系列会深入分析 Spring Cloud 的每一个组件，从Spring Cloud Commons这个 Spring Cloud 所有元素的抽象说起，深入设计思路与源码，并结合实际使用例子深入理解。本系列适合有一定 Spring 或者 Spring Boot 使用经验的人阅读。什么是Spring Cloud CommonsSpring Cloud框架包括如下功能：分布式多版本配置管理服务注册与发现路由微服务调用负载均衡断.

2021-01-18 10:30:26 18846

原创通过 JFR 与日志深入探索 JVM - TLAB JFR 相关事件与日志详解

全系列目录：通过 JFR 与日志深入探索 JVM - 总览篇上一篇我们详细的分析了 TLAB 的原理以及生命周期，并且提出 JFR 相关的两个事件：在线程分配对象时，如果 TLAB 不够，则根据最大允许浪费空间，决定是回收当前 TLAB 还是重新获取一个 TLAB 进行分配还是直接在堆上分配。jdk.ObjectAllocationOutsideTLAB 代表直接在堆上分配，jdk.ObjectAllocationInNewTLAB 代表回收+重新获取 TLAB 进行分配。我们也提到了，jdk.Ob.

2021-01-06 21:22:10 54456

原创通过 JFR 与日志深入探索 JVM - 1. JFR 简介与发展

什么是 Java Flight Record我们都知道，黑匣子是用于记录飞机飞行和性能参数的仪器。在飞机出问题后，用于定位问题原因。JFR（Java Flight Record）就是 Java 的黑匣子。JFR 是 Java Flight Record （Java飞行记录）的缩写，是 JVM 内置的基于事件的JDK监控记录框架。这个起名就是参考了黑匣子对于飞机的作用，将 Java 进程比喻成飞机飞行。顾名思义，这个记录主要用于问题定位和持续监控。在线上出问题时，我们一般首要任务是快速恢复，而不是保

2020-12-19 22:49:49 55897 2

原创通过 JFR 与日志深入探索 JVM - 总览篇

本系列会针对 Java 中高级开发人员以及 JVM 运维人员，帮助大家深入理解 JVM 原理并能学以致用定位线上瓶颈，线上性能问题以及长期持续监控 JVM 。本系列针对 OpenJDK 11 以后的版本，同时也会帮助用户升级到 OpenJDK 11。本专栏会从快速上手 JFR，可视化查看 JFR 引入，之后会详细分析每一个 JFR 事件对应的背后的 JVM 原理以及源码，并且结合 Java 测试代码生成这些 JFR 事件帮助大家更好的理解这些事件产生的原因，以及需要如何去优化，然后会给出一下通过 JFR 定

2020-12-18 17:46:31 55916 3

原创通过 JFR 与日志深入探索 JVM - TLAB 原理详解

什么是 TLAB？TLAB（Thread Local Allocation Buffer）线程本地分配缓存区，这是一个线程专用的内存分配区域。既然是一个内存分配区域，我们就先要搞清楚 Java 内存大概是如何分配的。我们一般认为 Java 中 new 的对象都是在堆上分配，这个说法不够准确，应该是大部分 new 的对象在堆上分配。还有一部分可能在栈上分配或者是 TLAB 中分配。同时，对于一些的 GC 算法，还可能直接在老年代上面分配，例如 G1 GC 中的 humongous allocation

2020-12-17 20:42:38 61939 6

原创微服务系统架构设计系列 - RateLimiter - 1. 限流器简介与一般算法

Key TakeAways限流器是一种防御性的编程实现方式，防止一个大型的分布式系统在不可预知的大流量到来的时候导致系统大规模故障。限流器可以设置在服务端，主要为了限制资源的使用。放在客户端主要考虑调用压力更加均匀。一般限流器有五种算法，分别是：令牌桶，漏斗桶，固定窗口，滑动日志（指的其实是广义上的滑动窗口），滑动窗口（这里指的是滑动日志+固定窗口结合的一种算法）。什么是限流器？限流器是一种限制某种操作在一定时间内的执行次数（例如每秒钟5次）或者执行量（例如每秒钟1G大小的数据）的机制。哪里会用

2020-12-10 18:56:40 23118 3

原创 JVM相关 - StackOverflowError 与 OutOfMemoryError

本文基于 Java 15StackOverflowError 与 OutOfMemoryError 是两个老生常谈的 Java 错误。Java 中的虚拟机错误 VirtualMachineError 包括以下四种：我们比较关心的就是 StackOverflowError 与 OutOfMemoryError，剩下的 InternalError 一般是内部使用错误，UnknownError 是虚拟机发生未知异常，这两种我们这里不讨论。虚拟机规范中的 StackOverflowError 与 Out.

2020-10-12 12:05:36 1131

原创 JDK核心JAVA源码解析(9) - hashcode 方法

本文基于 OpenJDK 11， HotSpot 虚拟机在开发过程中我们可能会经常接触到hashcode这个方法来生成哈希码，那么底层是如何实现的？使用时有何注意点呢？hashcode() 方法底层实现hashcode()是Object的方法：@HotSpotIntrinsicCandidatepublic native int hashCode();它是一个native的方法，并且被@HotSpotIntrinsicCandidate注解修饰，证明它是一个在HotSpot中有一套高效的实.

2020-09-16 17:44:51 1994 1

原创 Java GC详解 - 1. 最全面的理解Java对象结构 - 对象指针 OOPs

最近在抽时间阅读 JDK 的源码，主要是 GC 还有 Safepoint 相关的源码，发现很多我在之前拜读网上各种 JVM 原理大作时候的对于底层原理的误解。果然，一百个人读水浒传，就有一百种水浒传。还是需要更加深入的了解下源码，才能更好地理解 JVM，进行调优。这个系列，将在讲述 Java GC 各种原理的基础上，结合对应的源码分析，并附上源码地址。因为JVM的源码更新还是很快的，尤其是 GC 这一块，但是基本原理，应该大体不会变，附上源码地址，旨在让各位读者掌握这些原理最新实现情况。本文在撰写的时候，.

2020-09-16 17:42:48 1614 2

原创 Spring Cloud升级之路 - Hoxton - 10. 网关重试带Body的请求Body丢失的问题

带 Body 的重试 Body 丢失之前我们的配置里面，只对 Get 请求针对 500 响应码重试，但是针对像 Post 这样的请求，只对那种根本还没到发送 Body 的阶段的异常（例如连接异常）这种重试，那么如果我们要对带 Body 的 Post 进行重试呢？或者就是用 Postman 构建一个带 Body 的 Get 请求，重试是否正常呢？我们启动之前第6节的 EurekaServer，修改/test-exception-thrown接口，增加 RequestBody 参数：@RequestMap

2020-07-29 20:03:29 21056

原创 Spring Cloud升级之路 - Hoxton - 9. 针对网关非 Get 请求的重试

针对网关非 Get 请求的重试在之前的系列里面Spring Cloud升级之路 - Hoxton - 5. 实现微服务调用重试，我们针对 OpenFeign 和 Spring Cloud Gateway 都设置了重试。对于 OpenFeign：Get请求：任何非200 响应码，任何异常，都会重试。非 Get 请求：任何IOException（除了SocketTimeOutException，这个是read time out 导致的），还有 redilience 断路器异常，都会重试，其他的都不重试

2020-07-19 20:54:48 11559

原创 JVM相关 - SafePoint 与 Stop The World 全解(基于OpenJDK 11版本)

本文基于 OpenJDK 11在分析线上 JVM 性能问题的时候，我们可能会碰到下面这些场景：1.GC 本身没有花多长时间，但是 JVM 暂停了很久，例如下面：2.JVM 没有 GC，但是程序暂停了很久，而且这种情况时不时就出现。这些问题一般和 SafePoint 还有 Stop the World 有关。什么是 SafePoint？什么是 Stop the world？他们之间有何关系？我们先来设想下如下场景：当需要 GC 时，需要知道哪些对象还被使用，或者已经不被使用可以回收了，这样.

2020-07-19 20:32:21 33566 5

原创 Spring Cloud升级之路 - Hoxton - 8. 修改实例级别的熔断为实例+方法级别

实例级别的熔断带来的困扰如之前系列（Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断）所述，我们实现了实例级别的熔断。但是在生产中发现，并不是所有情况下都表现良好。首先如果发布了新接口，但是不小心回滚了，调用新接口就会报错，从而导致整个实例都不能访问。还有就是某些实例某个接口出现了问题，但是其他接口是好的，熔断掉整个实例有点浪费。于是乎，我们将实例级别的熔断改成实例 + 方法级别。对于 OpenFeign 修改首先，我们只针对断路器进

2020-07-14 10:24:08 16854

原创 JDK核心JAVA源码解析（8） - 自动封箱拆箱与效率的思考

想写这个系列很久了，对自己也是个总结与提高。原来在学JAVA时，那些JAVA入门书籍会告诉你一些规律还有法则，但是用的时候我们一般很难想起来，因为我们用的少并且不知道为什么。知其所以然方能印象深刻并学以致用。本文基于 Java 14在JDK1.5引入自动装箱/拆箱，让开发更高效。自动装箱时编译器调用valueOf()将原始类型值转换成对象，同时自动拆箱时，编译器通过调用类似intValue(),doubleValue()这类的方法将对象转换成原始类型值。自动装箱是将 boolean 值转换成 Bo

2020-06-16 20:19:38 3497

原创 Spring Cloud升级之路 - Hoxton - 7. 后续更新（WebFlux等）

1. 修正实例列表乱序导致的负载均衡重试相同实例的问题虽然之前考虑了通过每个请求的traceId隔离负载均衡的position来实现重试不会重试相同实例的问题，但是没有考虑在负载均衡过程中，实例列表的更新。例如：请求第一次调用负载均衡，实例列表是：[实例1，实例2]，position为1，对2取余=1，所以请求发送到实例2上面了请求失败，触发重试，实例列表缓存失效，更新后变成了：[实例2，实例1]，position为2，对2取余=0，所以请求又发送到实例2上面了private Response

2020-06-15 15:21:57 15162

原创 Spring Cloud升级之路 - Hoxton - 6. 场景测试

准备工作首先拉取项目源码：git clone https://github.com/HashZhang/spring-cloud-scaffold.git打开其中的 spring-cloud-hoxton 项目。启动Eureka启动zone1-service-provider-instance1，zone1-service-provider-instance2，zone1-service-provider2-instance1，zone2-service-provider-instance1这

2020-06-05 17:39:26 10167

原创 Spring Cloud升级之路 - Hoxton - 5. 实现微服务调用重试

feign 实现重试我们继续使用resilience4j实现重试，根据上一篇Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断，我们已经加载了RetryReqistry这个核心配置Bean。Retry相关的配置：create-and-configure-retry配置项默认值说明maxAttempts3最大重试次数，不包括本身那次调用waitDuration500[ms]重试间隔时间interva

2020-06-05 17:38:52 19854 6

原创 Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断

如何不启用Hystrix由于我们的入口注解类从@SpringCloudApplication替换成了SpringBootApplication，这样不会启用Spring-Cloud-CircuitBreaker。引入的Hystrix依赖也就没有效果。请参考本系列第二节： Spring Cloud升级之路 - Hoxton - 2.入口类注解修改与OpenFeign的改造使用Resilience4j实现实例级别的隔离与熔断为什么需要实例级别的熔断呢？因为某个微服务可能某些实例暂时不可用，我们希望在重试的

2020-06-05 11:13:39 19350 4

原创 Spring Cloud升级之路 - Hoxton - 3. 负载均衡从ribbon替换成spring-cloud-loadbalancer

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold负载均衡Ribbon替换成Spring Cloud Load BalancerSpring Cloud Load Balancer并不是一个独立的项目，而是spring-cloud-commons其中的一个模块。项目中用了Eureka以及相关的 starter，想完全剔除Ribbon的相关依赖基本是不可能的，Spring 社区的人也是看到了这一点，通过配置去关闭Ribbo.

2020-06-04 11:14:18 34044 2

空空如也

空空如也