如果项目中对于集合类型的Bean，同时存在两种注入方式：收集装配和直接装配。那么后者会失效。原因是因为Spring本质上就是从整个Spring容器中去寻找和集合元素类型相同的Bean。然后返回。倘若能够匹配到结果，就会直接返回。不会再根据类型进行自动装配。因此直接装配的方式会失效。另外，我们还注意到，1.1节案例中，对于收集装配方式，结果输出的是：这里原因是因为Spring加载Bean是根据自然顺序来的。我们声明BeanUserOne在前，UserTwo在后。倘若希望UserTwo先被加载，可以通过。

这篇文章是在Spring常见问题解决 - Body返回体中对应值为null的不输出？的基础上讲的。我们有时候，可能需要自定义一个序列化器来满足自己的需要，但是如果项目中不正确使用了注解，可能会导致这个自定义的序列化器失效。首先我们应该看下这个注解是拿来干啥的吧。项目中，如果我们希望自定义一些MVC的功能，我们只需要实现接口即可。无需添加注解。添加注解，会导致SpringBoot对MVC的自动装配失效。因为Spring对于类型的Bean只允许存在一个（包括其子类）。此时以序列化器为例，使用。......

进行参数校验的时候，请在Controller参数入口处，增加@Validted注解。倘若有级联属性，类里面嵌套类。需要在对应的属性上增加@Valid注解来表示支持级联校验。

然后我们可以自定义一个枚举异常类，定义了对应的异常原因和code。

封装的这一个环节，可想而知是发生在类的实例化阶段。我们可以在自定义的过滤器中加一个构造函数，然后打个断点，首先，我们从上面的调试流程来看，我们知道，我们项目中的。4.此时访问一下接口，结果如下：可见这个过滤器是正常运行的。在启动的过程中，是否对这个注解做出了一定的处理。首先，我们从上文的案例结果可以看出，此时我们自定义的。注解的作用是吻合的。这两者是有关联的，在下文会说。也就是说，我们执行这段代码，想要注册我们通过。从这个静态代码块，我们可以发现跟上文中讲到的。注解修饰的过滤器的时候，这个过滤器的类型是。

我在上一篇文章Java - HashMap原理分析中讲解了HashMap中主要的几个知识点。但是我们知道在高并发的情况下，HashMap并不是线性安全的。因此也就产生了与之对应的线性安全的Map，也就是。本质：取模运算在n是2的次幂时&(n-1)等价于% n。在Map扩容的时候，我们知道，扩容的大小是原本的2倍。而每个哈希槽中的数据要重新计算它的hash值。因为数组长度发生了改变。一个元素在扩容前和扩容后，都是通过的方式来获取哈希桶的下标的。我们举个例子，一个元素的哈希值是20（十进制）。当前Map。

根据上述的的描述，我们知道，过滤器链中的顺序的加载依赖：第一步骤：项目启动，会执行函数。此时会加载类型的Bean。第二步骤：此时会触发这个类的构造函数执行。构造函数中首先通过函数，按照顺序处理类型的Bean。是的一个子类。因此第二步中加载的实际上是。而最终又实现了Ordered接口。相关属性存在于其父类中。即order属性。构造函数将会对第二步中收集到的进行排序。先看排序对象是否实现了Ordered接口，若有，则调用getOrder()获取值。否则调用获取@Order注解属性值。我们通过。

在我之前的文章里，我讲到了关于MapJava - HashMap原理分析。Java - ConcurrentHashMap原理分析。Java - LinkedHashMap原理分析。我们知道是线性安全版本的HashMap，但是除此之外，在JavaHashtable，它也是一种键值对保存的集合。和HashMap相比，它是持线性安全的。不过在这里提个醒，Hashtable我觉得了解下就可以了，因为在高并发的情况下，我们往往会使用而不是Hashtable。除此之外，Hashtable已经被逐渐淘汰了。

HashMap一直是我们老生常谈的东西了，它可以说是Java里面最常用的一种集合了。虽然这块的内容比较基础，我也看过很多博主的文章，只不过这次，我希望能自己整理一下，并分享给各位读者。第一遍：从别人那学习。第二遍：自己整理一遍。第三遍：将心得分享一遍。例如写成文章。这个问题，是一个概率问题。加载因子越大：填满的元素越多，空间利用率越高，但发生冲突的概率也就越高。加载因子越小：填满的元素也就越少，空间利用率降低，但是发生冲突的概率也就越低。但是会提高resize的次数。

总结下JDK动态代理的几个知识点：1.首先，JDK动态代理要求被代理对象需要实现接口。2.动态代理会有一个缓存，用当前被代理类的类加载器和实现接口（虚引用）来作为一二级Key，两个组合起来可以拿到一个动态代理对象。返回的类型可能是代理对象本身，也可能是用于创建代理对象的Factory。3.动态代理的对象最终都是通过来返回。4.比较重要的就是，会判断目标类实现的接口中，是否是public修饰。来决定最终的代理类对象生成在哪个目录下。如果存在非public的接口并且不在同一个包内，那么抛出异常。

其实我们在遍历Map类型的集合的时候，有时候可能希望删除满足一定条件的key。但是这个时候就会发现，抛异常了。那么本文就以为例，来看下原理。

Java中，MapJava - HashMap原理分析。最常用的一种。Java - ConcurrentHashMap原理分析。高并发、线性安全就用它，用它！我们知道，HashMap关键就在于Hash。哈希值它并不能像数组那样是顺序的。因此我们插入的元素无法保证顺序性。因此，衍生出一个，本文就来讲解下它的原理。// 将元素移动到最后 void afterNodeAccess(Node < K , V > e) {

首先大家可以看这片文章去搭建一个最基础的SpringBoot整合MybatisMybatis - 预编译的运用和原理。

首先我们来说下预编译的一个背景：我们知道一条SQL语句到达Mysql之后，Mysql并不是会马上执行它，而是需要经过几个阶段性的动作(细节的可以查看Mysql复习计划（一）- 字符集、文件系统和SQL执行流程缓存的检查。解析器解析。优化器解析。执行器执行。那么这几个阶段肯定是需要一定的时间的。而有时候我们一条SQL语句可能需要反复的执行，只不过里面的参数可能不一样，比如where子句中的条件。如果每次都需要经过上面的几个步骤，那么效率就会下降。因此为了解决这种问题，就出现了预编译。

我们都知道Mybatis默认开启了一级缓存，二级缓存需要手动开启。我自己最近也在复习Mybatis相关的知识。但是在写的时候，发现一级缓存并没有生效，因此特此记录。首先可以看这篇文章Mybatis - 预编译的运用和原理搭建一个项目。创建一个SqlSession。如果当前的函数没有事务声明，则提交当前事务。关闭当前的SqlSession。程序执行了多次函数，调用相同的SQL，Mybatis默认开启了一级缓存，因此理论上来看，应该只有第一次是走了SQL。后续都是走缓存才对。但是实际上却每次都执行了。

上篇文章Mybatis - 一二级缓存的原理Cache实例和实例之间存在着映射关系。而从源码来看，二级缓存这个真实的数据是保存在Cache中的。那么问题来了：两者之间为什么还要做个映射呢？因此我在这篇文章中做个简要的分析。Mybatis使用一个映射缓存来解决脏读的问题。只有事务提交的时候，对应的数据才会放入到二级缓存中，否则无法读取。默认的情况下，Mybatis将一二级缓存都存储到本地缓存中。因此在单机器下，Mybatis本身引入这样的机制能解决二级缓存的脏读问题。

我们直到Mybatis一级缓存：默认开启。SqlSession级别。二级缓存：需要手动开启。namespace级别。那么在了解一二级缓存的原理之前，我们应该先知道其相关的知识。一级缓存默认开启，底层查询基于一级缓存实现。一级缓存的Key是一种MapperID+offset+limit+Sql+入参的组合。可以参考下图：3.一级缓存失效的原因总结：更新操作、事务提交、回滚、SqlSession会话关闭、。一级缓存属性设置为STATEMENT。

大家在平时开发中，肯定会有用到线程池。线程池也就是利用一种池化技术。将线程创建好后，保存起来，减少因为重复的创建和销毁而带来的资源消耗。submitexecute那么这两种方式有什么区别呢？本文就会详细的来讲讲。我们再来看下线程池的一个类关系图：execute函数是接口Executor下的方法。submit是接口下的方法。而Executor}另一方面，则是继承了Executor接口的基础上，定义了submitFuture

Mybatis - 单机器下二级缓存脏读问题的解决（TransactionalCache的运用）当时写的项目案例中，我发现事务回滚无法失效，虽然结果上并不影响二级缓存的一个结论。但是这个问题一直困扰了我好久。最后看了源码才发现问题出在哪里。