Java 开发 | 言七墨

使用 Feign 调用分页接口报错：Method has too many Body parameters @ApiOperation(value = "分页查询会话")@PostMapping(Routes.SESSIONS_QUERY)JsonResult<Pagination<SessionInfo>> querySessions(@RequestBody @Valid SessionsQo qo, @PageableDefault(size = 20, sort = "id", direction = Sort.Direction.DESC) Pageable pageable);...

10月12日 · 2020年

Spring 知识图解

Spring SpringBoot

1785 6 0

Spring 图解（持续更新中..）...

9月2日 · 2020年

多数据源下的单元测试优化

事务单元测试多数据源

1985 3 0

水平分表完成业务代码后，在运行单元测试时，出现了以下两个问题：事务不回滚性能极差：200 个单元测试方法，分表之前，平均耗时 12 分钟左右，分表之后，耗时 50 分钟左右...解释下，分表之前耗时 12 分钟左右的大概原因：对于持久层代码，没有 mock，直接走的 DB单元测试未使用 H2 等内存数据库，因为有一些操作 H2 不支持其它历史问题，下面会提及...

8月15日 · 2020年

图解 JVM

JVM 垃圾回收堆外内存守护线程逃逸分析

1597 8 0

年轻代和老年代都是使用的 G1 收集器年轻代收集：YGC(STW)：E 和 S(from) 区复制到 S(to)(是个 free Region)，然后清除 E 和 S(from) 区中未存活的对象MixGC(年、老年代收集(清理的不是很干净，但是清理的时间特别短))：1、初始标记 (标记 GCroot 直接引用的对象和所在的 Region，这里不止标记 O 区，初次标记一般和 YGC 的 STW 同时进行) 2、根区间扫描（扫描 GCroot 所在的 Region 到 Old 区的引用）3、并发标记（类似 CMS，但是标记的是整个堆，而不是只有 O 区。这期间如果发现某个 Region 所有对象都是\'垃圾\'则标记为 X）4、重新标记（同 CMS，并且将上一步中的 X 区删除，另外，用了 SATB，速度更快，也是 STW）5、复制清理（选择所有 Y 区 Reigons 和\'对象存活率较低\'的 O 区 Regions 组成 Csets，进行复制清理，STW）其实我们不需要完全的清理干净，每次我们只清理大部分也能保证系统的正常运行，这就是 MixGC 做的事情，做个不恰当的比喻，你妈让你打扫房间，你只把眼皮子底下的垃圾捡了就可以过关了，而不用把床底和桌角的垃圾扫干净...

8月15日 · 2020年

OSI七层模型、TCP/IP四层模型

OSI七层模型 TCP/IP四层模型

1311 2 0

七层负载均衡：基于虚拟的 URL 或主机 IP 的负载均衡。在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如 HTTP 协议 URI 或 Cookie 信息，实现七层负载均衡。此种负载均衡器能理解应用协议。...

3月29日 · 2020年

线上 JVM 堆内存不足引发BeanCreationNotAllowedException

BeanCreationNotAllowedException JVM

2674 10 0

线上 JVM 堆内存不足引发BeanCreationNotAllowedException背景某个周六的中午，领导突然找我说线上有大量报错，让我看一下。我发现日志中出现了很多下面的报错信息，而且持续了一段时间（后面才发现收到了告警邮件，但是当时手机没有提醒，强行甩锅...）：...

3月27日 · 2020年

多种状态字段的查询性能优化案例

分页查询性能优化状态字段

2229 13 0

多种状态字段的查询性能优化案例前提问题当分页查询消息的时候，会查询符合条件的消息total数量，这个操作在查询消息数量比较多的时候，很容易出现timeout（从库查询一万多条消息，count 一下，需要90多秒），经查证，是现有receiver_visible_roles字段导致的：receiver_visible_roles存储：目前这个字段是存了5种角色的可见性，1代表可见，0代表不可见，从高位到低位依次代表：E、D、C、B、A。假如A、B可见，其余角色不可见，则存储00011。receiver_visible_roles查询：假如查A、B可见，其余角色没有限制，则需要 in (00011, 00111, 01011, 01111, 10011, 10111, 11011, 11111)，虽然该字段建有索引，并用到了索引，但还是很慢。另，假如再新增角色，查询性能会更慢......