xiaozhigang

简述

提到分布式，那么CAP原则是绕不过去的，那么什么是CAP原则呢。

CAP原则：在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）不可能都同时满足，最多只能同时满足两个。

详解

为什么不能CAP兼容

1、在分布式系统中，分区容错性肯定是必须的，所以必须要有P。

2、添加C，就是添加一致性，那么就是要保证所有分区中的数据是一致的。假设有A、B、C三个分区，现在分区上的数据一致。

3、添加A，添加可用性，保证服务一直可用，我们看能不能达到这种效果。

​ A、B、C三个分区，分区上的数据一致。现在操作A分区中的数据发生更改，在保证一直性的情况下，得先同步更改B、C分区上得数据。更改数据需要时间，在同步更改的这段时间中，是不是就不能对外提供服务。 如果要先保证可用性，那是不是就不能先同步更改B、C分区上的数据。由此就可以看出CAP不能同时存在。

解决方案

虽然CAP不能同时存在，但是在分布式系统中一般AP、CP也可以根据场景的不同解决我们的问题了。

在可用性要求高的场景中，可以放弃一致性。这要求在数据不一致的情况下不影响我们的服务，比如NoSQL。

在一致性要求高的场景中，可以放弃可用性。这种场景是对数据有很高的要求，比如转账服务，可以牺牲一段可用时间，以保证各分区数据同步一致。

折中方案

在一致性要求比较高的场景中，同步各分区的时候，是不是需要同步到所有分区，如果同步一个或者大部分分区就可以的，那么这时候返回，是不是会提高可用性。这是一个在保证一致性的情况下提高可用性的办法，前提是同步到一个或大部分分区就可以保证我们的业务。

归根究底，一致性和可用性不能同时兼得，一个增加另一个必然减少。

架构图

四层结构

1. 适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；

2. 应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；

3. 领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；

4. 基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。

   阅读全文 »

简述

ThreadLocal是什么，是java中用于实现线程内变量的工具类。允许每个线程都拥有自己的副本，从而实现线程隔离，解决多线程的共享对象的线程安全问题。

ThreadLocal的使用

1
2
3

public static ThreadLocal<String> localVariable = new ThreadLocal<>(); // 新建
localVariable.set("他是沙雕"); // 设置值
String value = localVariable.get(); // 获取值

详述

实现原理

ThreadLocal的底层实现是一个特殊的map，可以理解往ThreadLocal设置一个xxx值，就是往这个特殊的map中设置一个key为当前线程，value为xxx的值。由于他的key只能为当前线程，所以在某个线程中set和get都不会影响其他线程，从而到达线程安全。下图的ThreadLocalMap就是拿个特殊的map。

总体来说，java在运行的过程中会维护一个ThreadLocalMap，这个ThreadLocalMap的key为各个线程，value为各个线程想存放的东西，可以是String，可以是map，List等等。当时由于key为各个线程，所有每个线程只能由一个Entry ，也就是一个键值对（key-value），当然线程也可以不设置不存放。

内存泄露

都知道ThreadLocal会内存泄漏，那么这个内存泄漏又是怎么回事。

都知道在java虚拟机中栈是私有的，而堆是共享的，所以ThreadLocalMap是存放在堆中的，而栈中存的只是一个引用，如下图。

由于Entry extends WeakReference<ThreadLocal<?>>，所以可以看到，Entry中的key指向ThreadLocal是弱引用，也就是线程执行完之后，这个ThreadLocal就会被释放清理掉，但是由于ThreadLocalMap指向Entry是强引用，所以Entry不会被释放清理，如果这Entry一直不被清理释放，那么ThreadLocalMap的内存占用就会越来越大，以至于内存也漏。

所以为了防止这种问题的发生，在用完时，记得释放清理。

1
2
3
4
5
6

try {
    threadLocal.set(value);
    // 执行业务操作
} finally {
    threadLocal.remove(); // 确保能够执行清理
}

简述

IoC是指控制反转，是指有容器来控制对象的生命周期和对象之间的关系。简单来说就是之前使用对象首先需要new一个对象，而现在直接从容器中取就可以了。这就像有小农经济转变到商品经济。

小农经济：自给自足，什么东西都需要自己动手也就类似于对象需要自己new。

商品经济：需要啥去商店买就行，这里的商店就相当于容器，商品就相当于对象，生成商品的工厂就相当于对象工厂等。

Spring IOC 的简单实现

分析

1、首先我们得有一个容器，这个容器负责保存和生成bean，这也就是对象工厂BeanFactory 。

2、其次，得有一个bean注册器，这负责bean的注册和真正生成。

3、然后，还得有一个资源加载器，用来加载bean的定义

4、最后，得有一个bean的定义模型和配置文件。

实现

分析为倒叙分析，实现就得看正序实现了，不然依赖就颠倒了。

1、配置文件和bean模型

先准备一个示例的bean

1
2
3
4
5

public class BeanExample {
    public void print(String string){
        System.out.println("test out: " + string);
    }
}

配置文件，偷懒使用一个<key,value>键值对代替

1

beanExample:com.shopmall.springIoc.BeanExample

bean模型定义

1
2
3
4
5
6
7
8

@Getter
@Setter
public class BeanDefinition {
    private String beanName;

    private Class beanClass;
}

2、资源加载器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class ResourceLoader {
    public static Map<String, BeanDefinition> getResource() {
        Map<String, BeanDefinition> beanDefinitionMap = new HashMap<>();
        Properties properties = new Properties();
        try {
            InputStream inputStream = ResourceLoader.class.getResourceAsStream("/beans.properties");
            properties.load(inputStream);
            for (String key : properties.stringPropertyNames()) {
                String className = properties.getProperty(key);
                BeanDefinition beanDefinition = new BeanDefinition();
                beanDefinition.setBeanName(key);
                Class clazz = Class.forName(className);
                beanDefinition.setBeanClass(clazz);
                beanDefinitionMap.put(key, beanDefinition);
            }
            inputStream.close();
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
        return beanDefinitionMap;
    }
}

3、对象注册器

简化过程，都用单例了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public class BeanRegister {

    //单例Bean缓存
    private final Map<String, Object> singletonBeanMap = new HashMap<>();

    /**
     * 获取单例Bean
     *
     * @param beanName bean名称
     * @return Object 单例Bean
     */
    public Object getSingletonBean(String beanName) {
        return singletonBeanMap.get(beanName);
    }

    /**
     * 注册单例bean
     *
     * @param beanName bean名称
     * @param bean 单例bean
     */
    public void registerSingletonBean(String beanName, Object bean) {
        if (singletonBeanMap.containsKey(beanName)) {
            return;
        }
        singletonBeanMap.put(beanName, bean);
    }

}

4、容器bean工厂

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

public class BeanFactory {
    private Map<String, BeanDefinition> beanDefinitionMap = new HashMap<>();

    private BeanRegister beanRegister;

    public BeanFactory() {
        //创建bean注册器
        beanRegister = new BeanRegister();
        //加载资源
        this.beanDefinitionMap = new ResourceLoader().getResource();
    }

    /**
     * 获取bean
     *
     * @param beanName bean名称
     * @return Object Bean
     */
    public Object getBean(String beanName) {
        //从bean缓存中取
        Object bean = beanRegister.getSingletonBean(beanName);
        if (bean != null) {
            return bean;
        }
        //根据bean定义，创建bean
        return createBean(beanDefinitionMap.get(beanName));
    }

    /**
     * 创建Bean
     *
     * @param beanDefinition bean定义
     * @return Object Bean
     */
    private Object createBean(BeanDefinition beanDefinition) {
        try {
            Object bean = beanDefinition.getBeanClass().newInstance();
            //缓存bean
            beanRegister.registerSingletonBean(beanDefinition.getBeanName(), bean);
            return bean;
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }
}

5、测试运行

简述

都知道spring的自动加载是通过注解实现的，但是这注解又是怎么实现的呢？

通过@SpringBootApplication注解开启，读取配置文件中的配置类，然后过滤掉不需要的配置类，最后将剩余的配置类加载配置。

具体过程

上面说了一下大概的概念，接下来我们分析一下具体的执行过程。

1、开启自动加载

都知道自动开启加载注解@SpringBootApplication，但是这个注解是个复合注解，他是由多个注解合并而成，但是主要的是三个注解：

1
2
3

@SpringBootConfiguration // 配置文件
@EnableAutoConfiguration // 开启自动配置
@ComponentScan // 扫描

@EnableAutoConfiguration注解继续下钻，主要有@AutoConfigurationPackage和@Import({AutoConfigurationImportSelector.class})两个注解，@AutoConfigurationPackage继续下钻主要有@Import({AutoConfigurationPackages.Registrar.class})这个注解。

所以基本可以理解

@EnableAutoConfiguration = @Import({AutoConfigurationImportSelector.class}) + @Import({AutoConfigurationPackages.Registrar.class})

即自动加载主要是依赖AutoConfigurationImportSelector.class，AutoConfigurationPackages.Registrar.class两个类。

2、@EnableAutoConfiguration下的两个类

AutoConfigurationPackages.Registrar.class：作用就是获取要扫描的包路径

1
2
3
4
5
6
7
8
9
10
11
12

static class Registrar implements ImportBeanDefinitionRegistrar, DeterminableImports {
    Registrar() {
    }

    public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
        AutoConfigurationPackages.register(registry, (String[])(new PackageImports(metadata)).getPackageNames().toArray(new String[0]));
    }

    public Set<Object> determineImports(AnnotationMetadata metadata) {
        return Collections.singleton(new PackageImports(metadata));
    }
}

AutoConfigurationImportSelector.class：可以看到AutoConfigurationImportSelector实现了3种接口

1、DeferredImportSelector接口，继承了ImportSelector接口，用于bean的注入

2、以Aware结尾的接口，这类接口时为了完成某类资源的设置。

3、Ordered接口，用于指定bean的加载顺序。

1

public class AutoConfigurationImportSelector implements DeferredImportSelector, BeanClassLoaderAware, ResourceLoaderAware, BeanFactoryAware, EnvironmentAware, Ordered

3、AutoConfigurationImportSelector

AutoConfigurationImportSelector实现了DeferredImportSelector接口，我们先看一下DeferredImportSelector接口。

接口里就包含了要加载的bean信息，再回到实现类，主要方法process。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Override
public void process(AnnotationMetadata annotationMetadata, DeferredImportSelector deferredImportSelector) {
	Assert.state(deferredImportSelector instanceof AutoConfigurationImportSelector,
			() -> String.format("Only %s implementations are supported, got %s",
					AutoConfigurationImportSelector.class.getSimpleName(),
					deferredImportSelector.getClass().getName()));
					
	// 获取自动配置的类
	AutoConfigurationEntry autoConfigurationEntry = ((AutoConfigurationImportSelector) deferredImportSelector)
			.getAutoConfigurationEntry(annotationMetadata);
	this.autoConfigurationEntries.add(autoConfigurationEntry);
	// 遍历自动配置的bean
	for (String importClassName : autoConfigurationEntry.getConfigurations()) {
		// 如果存在这个类就进行加入
		this.entries.putIfAbsent(importClassName, annotationMetadata);
	}
}

其中，主要的就是获取自动配置类：getAutoConfigurationEntry方法

protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
    if (!isEnabled(annotationMetadata)) {
        return EMPTY_ENTRY;
    }
    AnnotationAttributes attributes = getAttributes(annotationMetadata);
    List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes); // 关键
    configurations = removeDuplicates(configurations);
    Set<String> exclusions = getExclusions(annotationMetadata, attributes);
    checkExcludedClasses(configurations, exclusions);
    configurations.removeAll(exclusions);
    configurations = getConfigurationClassFilter().filter(configurations);
    fireAutoConfigurationImportEvents(configurations, exclusions);
    return new AutoConfigurationEntry(configurations, exclusions);
}

根据关键代码继续下钻

protected List<String> getCandidateConfigurations(AnnotationMetadata metadata, AnnotationAttributes attributes) {
    List<String> configurations = new ArrayList<>(
            SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader()));
    ImportCandidates.load(AutoConfiguration.class, getBeanClassLoader()).forEach(configurations::add);
    Assert.notEmpty(configurations,
            "No auto configuration classes found in META-INF/spring.factories nor in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. If you "
                    + "are using a custom packaging, make sure that file is correct.");
    return configurations;
}

继续下钻

到这就基本清楚了，这里加载了META-INF/spring.factories文件下的配置，然后返回到getAutoConfigurationEntry方法里进行过滤，当然过滤的方式也是按条件注解@ConditionalOnxxx过滤生效。

总结

@SpringBootApplication下分三个注解，@EnableAutoConfiguration注解负责自动加载配置，

@EnableAutoConfiguration注解又引入两个类，AutoConfigurationImportSelector.class 和 AutoConfigurationPackages.Registrar.class

主要逻辑都在AutoConfigurationImportSelector.class中，此类中有个getAutoConfigurationEntry方法，

这个方法调用了两个方法getCandidateConfigurations 加载 和 getConfigurationClassFilter().filter 过滤。

如此加载进了配置文件中的配置，过滤了条件不满足的配置，以达到开箱即用。

代理模式

Spring AOP 就是基于代理模式，被代理对象有实现某个接口，则用JDK Proxy创建对象，没有实现接口则用Cglib创建代理对象。

当然也可以使用AspectJ，AspectJ是Java生态系统中最完整的AOP框架。

Spring AOP属于运行时增强，AspectJ是编译时增强。

两者异同：https://developer.aliyun.com/article/720402

模板方法

父类定义算法骨架或者关键步骤，而具体实现延迟到子类中，使子类再不改变父类结构的情况下可重定义某些特定步骤的实现。

Spring 中 JdbcTemplate、HibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。一般情况下，我们都是使用继承的方式来实现模板模式，但是 Spring 并没有使用这种方式，而是使用 Callback 模式与模板方法模式配合，既达到了代码复用的效果，同时增加了灵活性。定义了资源获取、执行SQL、释放资源这些基本流程，执行sql的具体方式又以回调函数的形式开放。

参考文献：https://blog.csdn.net/zhangweiocp/article/details/115486257

观察者模式

观察者模式是一种对象行为型模式。它表示的是一种对象与对象之间具有依赖关系，当一个对象发生改变的时候，依赖这个对象的所有对象也会做出反应。Spring 事件驱动模型就是观察者模式很经典的一个应用。Spring 事件驱动模型非常有用，在很多场景都可以解耦我们的代码。比如我们每次添加商品的时候都需要重新更新商品索引，这个时候就可以利用观察者模式来解决这个问题。

事件驱动模型中的三种角色：事件角色、事件监听者角色、事件发布者角色。

spring的事件流程总结

1、定义一个事件: 实现一个继承自ApplicationEvent，并且写相应的构造函数

2、定义一个事件监听者：实现 ApplicationListener 接口，重写 onApplicationEvent() 方法

3、使用事件发布者发布消息: 可以通过 ApplicationEventPublisher 的 publishEvent() 方法发布消息

example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// 定义一个事件,继承自ApplicationEvent并且写相应的构造函数
public class DemoEvent extends ApplicationEvent{
    private static final long serialVersionUID = 1L;

    private String message;

    public DemoEvent(Object source,String message){
        super(source);
        this.message = message;
    }

    public String getMessage() {
         return message;
          }


// 定义一个事件监听者,实现ApplicationListener接口，重写 onApplicationEvent() 方法；
@Component
public class DemoListener implements ApplicationListener<DemoEvent>{

    //使用onApplicationEvent接收消息
    @Override
    public void onApplicationEvent(DemoEvent event) {
        String msg = event.getMessage();
        System.out.println("接收到的信息是："+msg);
    }

}
// 发布事件，可以通过ApplicationEventPublisher  的 publishEvent() 方法发布消息。
@Component
public class DemoPublisher {

    @Autowired
    ApplicationContext applicationContext;

    public void publish(String message){
        //发布事件
        applicationContext.publishEvent(new DemoEvent(this, message));
    }
}

当调用 DemoPublisher 的 publish() 方法的时候，比如 demoPublisher.publish("你好") ，控制台就会打印出:接收到的信息是：你好 。

装饰者模式

装饰者模式可以动态地给对象添加一些额外的属性或行为。相比于使用继承，装饰者模式更加灵活。简单点儿说就是当我们需要修改原有的功能，但我们又不愿直接去修改原有的代码时，设计一个 Decorator 套在原有代码外面。最典型的就是JDK中的InputStream,OutputStream，两个类下的所有子类都是再不修改父类代码的情况下扩展了他的功能。

总结

Spring 框架中用到了哪些设计模式？

• 工厂设计模式 : Spring 使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
• 代理设计模式 : Spring AOP 功能的实现。
• 单例设计模式 : Spring 中的 Bean 默认都是单例的。
• 模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
• 包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
• 观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
• 适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controllerl

分支定义

1. master

   1 2 3

   长期分支，存在与整个项目开发过程。 由项目主要技术负责人管理该分支。

2. release/xxx

   1 2 3 4

   release/test 和 release/prod 既可以为长期分支也可以为短期分支，可能存在于一个或者多个版本之间. 由测试负责人负责人管理该分支。

3. feature/fixbug/hotfix

   1 2 3 4 5

   临时分支 用于开发的具体功能特性和修复bug的分支，功能完成后删除. 格式为：feature_$date_$name_$description fixbug_$date_$name_$description hotfix_$date_$name_$description

两段式提交是MySQL数据持久化的保证。

两种日志

binlog和redolog

binlog记录了数据库表结构和表数据变更，主要有两个作用：复制和恢复数据

redo log 是 Innodb 引擎独有的日志模块，它只记录有关 Innodb 引擎的事务日志，记录内容为 对数据页的物理操作

两段式提交

两种日志虽然都保证持久化，但是侧重点不同。

1、redo log（重做日志）让InnoDB存储引擎拥有了崩溃恢复能力。

2、binlog（归档日志）保证了MySQL集群架构的数据一致性，主从节点的同步都是通过binlog保证的。

如果单独提交
先写 redo log 后写 binlog，也就是事务可能还没有提交，系统崩溃了，虽然可以通过redo log恢复，但是binlog还没有这条数据，就会造成主从不一致 先写 binlog 后写 redo log，这个过程说明事务已经提交了，系统崩溃了，虽然binlog里面有数据，但是redo log里面没有，也会发生主从不一致，并且redo log因为不全，即使重新恢复的时候也不是最新的数据

两段式提交

就是将redolog的提交拆为两各阶段，prepare阶段和commit阶段，在中间插入binlog提交。

发生异常

1、在prepare阶段写入redolog的时候发生异常，那不管redolog有没有写完，都会回滚，因为binlog没有写入，会导致日志不一样，主从数据不一致。

2、在commit阶段写入binlog的时候发生异常

    如果在写完之前，那也会回滚，毕竟没写完和没写一样，会导致日志不一样，主从数据不一样。

    如果在写完之后，那就不会回滚了，两种日志都写完了，能保证数据一致了。

3、在commit阶段提交redolog的时候发生异常，前面写完binlog就不会回滚了，那这里也不会回滚，能保证数据一致性。

简述

说起回表，肯定要说起MySQL的存储结构B+树。

每条数据是以主键和数据的形式存放在B+树的节点上，如果我们通过主键查询的话，直接通过和节点上的主键比较判断，相等的话直接取。

其他索引是将索引和主键值放在一起的，通过索引查到主键，在通过主键去查找数据。这也就是为什么主键索引会比其他索引快。

主键查询

主键和数据是通过B+数的形式存储的，查的时候肯定也是通过树的查询方式查询的。如下图查询主键Id为4的数据，先根据根节点查询，4小于10，再往子节点查找，然后跟子节点的值比较，在2、4之间，再寻找这区间的节点，第一个值是3，不匹配，在查找下一个，值是4匹配，放回数据记录data。

非主键索引查询

其实和主键查询差不多，只不过相当于两次主键索引查询，第一个查询到的不是数据，是主键值，再根据主键值，按照主键索引查询再来一次。如图，如果数据有一条数据是2019-04-01创建的，数据的主键id为4，我们想根据这个创建时间（不知道主键id）找到这条数据。那就是先根据创建时间找到主键4，后根据主键4找到记录数据data。

回表

分主键索引相当于两次查询，第一次查询主键，第二次查询数据，将第二次查询的数据结果放回给第一次查询结果，就叫回表。按照上面的图示，就是将data放回到创建时间的查询中。

覆盖查询

使用非主键查询的时候，也会存在不用回表的情况，这种叫做覆盖查询。

什么是覆盖查询呢，就是在我们使用索引的时候，索引本身包含的数据字段已经满足查询要求的字段了，就不用具体根据主键去找具体的记录数据了。

如果有一份人员信息数据，存有名称，性别，出生日期和其他一些字段。由于通过出生日期和性别的查询较多，我们用这两个字段构建了一个联合索引。现在我们要查询2019-04-01出生的女孩人数。

如图，联合索引按出生日期和性别联合构建的索引，先按出生日期排序，再按性别排序。通过索引，查询到只有一个主键为4满足，这时候我们需要计数，因为主键是唯一的，也不需要我们通过主键再次查询了，计算主键数量就够了，直接返回1。这就不用回表。

最左覆盖原则

上面我们说到根据联合索引查询，其实联合索引有两个值，我们只根据一个值去查询的，但也查询到了。这是为啥呢，这就是最左覆盖原则。根据我们的查询条件，会匹配索引，从左边第一个字段开始，所以我们查询的时候有条件过滤最好和索引顺序一直。如上图，我们查询的是整个表里面有女生多少人就没办法走联合索引了。

扩展

是不是觉得这个B+树还挺好用的，思路挺清晰的。但是如果我们的B+树层级很深，是不是查询比较的次数就多了，耗时也就多了，也就不好用了。所以大家知道B+树有多少层吗？

B+树一般是34层，为啥说34层呢，这也是个计算值，我们看一下具体怎么计算的。

MySQL的引擎是InnoDB，InnoDB默认页大小是16k，当然也可以设置，B+树的每个节点都是一页。从上面可以知道，节点分为数据节点和非数据节点，

在数据节点中，通常数据大小为1k，16k / 1k = 16，也就是每个数据页中大概会存放16条数据。

在非数据节点中，主要存放的是主键ID和指针，主键大概8字节，指针大概6字节，总共14字节，1k=1024字节，整页可以存放1170个（16 * 1024 / 14 = 1170）。

在3层的情况下，2层非数据节点，1层数据节点，可以存放大概21902400条数据。1170117016=21902400，已经到千万级别了，一个表里放千万条数据已经很大了，再大就要考虑分库分表了。

结构简述

HashMap和ConcurrentHashMap的结构都是一样的，jdk1.8之后都是 数组+链表+红黑树，链表长度超过8之后转红黑树。

计算

节点为6个的时候，链表的平均查询时间：(1+2+3+4+5+6)/ 6 = 3.5，红黑树的平均查询时间 (1+22+33)/6=2.3

节点为7个的时候，链表的平均查询时间：(1+2+3+4+5+6+7)/ 7 = 4，红黑树的平均查询时间 (1+22+34)/7=2.4

节点为8个的时候，链表的平均查询时间：(1+2+3+4+5+6+7+8)/ 8 = 4.5，红黑树的平均查询时间 (1+22+34+1*4)/8=2.6

链表的时间复杂度为O(n)，而树的时间复杂度为O(ln n)，上面计算有明显的效率变化，至于为啥选8这个阈值，应该是基于大量数据收集之后比较而定的。

结构图

HashMap

流程图

代码详解

ConcurrentHashMap

流程图

代码详解