HashMap 并发死循环分析
前言HashMap 存在并发死循环的问题,在1.7版本之前是因为多线程并发调用 put 方法容易产生环状链表,之后如果再调用get方法,如果刚好命中环状链表所在的槽位,则会用导致死循环,使得 CPU 占用率飙升.在JDK 1.8 之后,这一问题得到了修复,但是仍旧在某些特殊的情况下会发生另外一种死循环。这里就这两种情况逐一进行分析.链表的插入方式在分析之前,我们先了解一下链表的两种插入方式:头插法
前言HashMap 存在并发死循环的问题,在1.7版本之前是因为多线程并发调用 put 方法容易产生环状链表,之后如果再调用get方法,如果刚好命中环状链表所在的槽位,则会用导致死循环,使得 CPU 占用率飙升.在JDK 1.8 之后,这一问题得到了修复,但是仍旧在某些特殊的情况下会发生另外一种死循环。这里就这两种情况逐一进行分析.链表的插入方式在分析之前,我们先了解一下链表的两种插入方式:头插法
JavaAPI 的结构(sharding-jdbc的版本为 5.3.1)Sharding-JDBC 的 JavaAPI 的结构如下图所示,整体上,分为两大块:rule: 表的基本配置,如逻辑表名,物理节点等.stategy: 库和表的分片策略、主键生成、审计等策略的配置.所以在具体的配置时,也是按照这个框架进配置,具体的关系我再画了张图,便于理解:由于在我的项目里没有用到审计,所以审计(audit
ShardingSpherehttps://shardingsphere.apache.org/document/current/cn/overview/官方文档将 ShardingSphere 定义为 分布式的数据库生态系统它包含 Sharding-JDBC 和 Sharding-Proxy 两部分:Sharding-JDBC: 在 Java 的 JDBC 层上提供额外的服务ShardingSp
背景项目中需要动态的配置规则,所以技术选型上选择了跟Java融合度比较高的 Groovy(因为可以直接调用java的类库),但是由于缺乏groovy实战经验,在项目开发过程中遇到了以下问题:JVM metaspace 持续 OOM即在项目部署后,业务调用量上来后,Metaspace 空间持续不断上涨,当 commited 的大小接近 Metaspace 的设置值(-XX:MetaspaceSize
概述整体方案提到搭建属于自己的影视库,大家首先想到的应该是 NAS,由于阿里云网盘的不限速,给了像我一样没有 NAS ,但却爱看电视,又不想每次都下载下来看的人,一个搭建属于自己影视库的机会。这个方案我画了个简单的图:软路由连接在光猫和无线路由器之间,并且在其中安装 AlistAppleTV 盒子与无线路由器之间通过网线口进行连接(实测无线网速跟有线有很大差距)在需要观影的所有设备上安装 Infu