K O N GHashMap 并发死循环分析
前言HashMap 存在并发死循环的问题，在1.7版本之前是因为多线程并发调用 put 方法容易产生环状链表，之后如果再调用get方法，如果刚好命中环状链表所在的槽位，则会用导致死循环，使得 CPU 占用率飙升.在JDK 1.8 之后，这一问题得到了修复，但是仍旧在某些特殊的情况下会发生另外一种死循环。这里就这两种情况逐一进行分析.链表的插入方式在分析之前，我们先了解一下链表的两种插入方式：头插法
Sharding-JDBC 分库分表-基于JavaAPI
JavaAPI 的结构（sharding-jdbc的版本为 5.3.1）Sharding-JDBC 的 JavaAPI 的结构如下图所示，整体上，分为两大块：rule: 表的基本配置，如逻辑表名，物理节点等.stategy: 库和表的分片策略、主键生成、审计等策略的配置.所以在具体的配置时，也是按照这个框架进配置，具体的关系我再画了张图，便于理解：由于在我的项目里没有用到审计，所以审计（audit
Sharding-JDBC 分库分表-基于Yaml配置
ShardingSpherehttps://shardingsphere.apache.org/document/current/cn/overview/官方文档将 ShardingSphere 定义为 分布式的数据库生态系统它包含 Sharding-JDBC 和 Sharding-Proxy 两部分：Sharding-JDBC: 在 Java 的 JDBC 层上提供额外的服务ShardingSp
Java项目中引入Groovy的优化过程
背景项目中需要动态的配置规则，所以技术选型上选择了跟Java融合度比较高的 Groovy(因为可以直接调用java的类库)，但是由于缺乏groovy实战经验，在项目开发过程中遇到了以下问题：JVM metaspace 持续 OOM即在项目部署后，业务调用量上来后，Metaspace 空间持续不断上涨，当 commited 的大小接近 Metaspace 的设置值（-XX:MetaspaceSize