学习笔记（每天持续更新）

数据结构

B树(B-树)和B+树

https://my.oschina.net/u/4116286/blog/3107389

红黑树

二叉查找树：
左子树值均小于根节点，右子树均大于根节点
左右子树均为二叉排序树（二分查找的思想）

二叉查找树的缺点：
不断地插入递增或者递减的值，可能会变成线性表

即将二叉查找树变成一种平衡树

红黑树就是一种策略，也就是说红黑树是一种平衡二叉查找树

红黑树特点：

1. 节点是红色或者黑色
2. 根节点是黑色
3. 每个叶子的节点都是黑色的空节点（NULL）
4. 每个红色节点的两个子节点都是黑色的。
5. 从任意节点到其每个叶子的所有路径都包含相同的黑色节点。

....变色和旋转，理解不动啊。。。

数据库

索引的失效情况

1. 条件中有or，无论什么索引都会失效
   • 可以用in
   • 使用or，又想索引生效，只能将or条件中的每个列都加上索引
2. 复合索引中需要遵循最左前缀
   • 比如有(A,B,C)索引，索引生效的情况有A,AB,ABC
   • 如果查询中有AC这样，那么只有A索引条件生效
3. 范围查询后面的查询，索引不成效
   • A=x，B>x,C=x,C不生效
4. 在索引上进行运算，索引失效
5. 字符串没有单引号，索引失效
6. 尽量使用覆盖索引（只访问索引的查询（索引列完全包含查询列）），减少select * 。查询列，超出索引列，也会降低性能。
7. 以%开头的Like模糊查询，索引失效。
   • 如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。
8. in 走索引， not in 索引失效。
9. 尽量使用复合索引，而少使用单列索引
   • 创建复合索引(A,B,C),相当于创建了A，A+B，A+B+C

索引的结构，这里说的是B+树索引

https://blog.csdn.net/weixin_30531261/article/details/79312676

• 索引为什么不能是链表结构

假设有name索引，在我们找到第一个name属性为“Jesus”的节点后，继续往后找，当遇到name属性不为“Jesus”的节点时，就无需再往后查找了，因为节点是根据name属性有序排列的啊。假设第一个name=“Jesus”的节点是第499个节点，最后一个name=“Jesus”的节点是第500个节点，那么只需要遍历501个节点就可以了。当发现第501个节点的name字段不为“Jesus”，后面的499个节点也就无需遍历了。

但是这样的话前500次查询是很慢的，效率太低了。

• 索引为什么不能是平衡二叉树
  平衡树的查找时间复杂度是O(log2N)，已经很不错了

索引是存在于索引文件中，是存在于磁盘中的。因为索引通常是很大的，因此无法一次将全部索引加载到内存当中，因此每次只能从磁盘中读取一个磁盘页的数据到内存中。而这个磁盘的读取的速度较内存中的读取速度而言是差了好几个级别。

注意，我们说的平衡二叉树结构，指的是逻辑结构上的平衡二叉树，其物理实现是数组。然后由于在逻辑结构上相近的节点在物理结构上可能会差很远。因此，每次读取的磁盘页的数据中有许多是用不上的。因此，查找过程中要进行许多次的磁盘读取操作。

而适合作为索引的结构应该是尽可能少的执行磁盘IO操作，因为执行磁盘IO操作非常的耗时。因此，平衡二叉树并不适合作为索引结构。

• 为什么B树适合做索引
  B树是为了充分利用磁盘预读功能来而创建的一种数据结构
  • 磁盘的局部性原理：
    磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。
    程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。

B树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。每次读取磁盘页时就会读取一整个节点。也正因每个节点存储着非常多个关键字，树的深度就会非常的小。进而要执行的磁盘读取操作次数就会非常少，更多的是在内存中对读取进来的数据进行查找。

B树的查询，主要发生在内存中，而平衡二叉树的查询，则是发生在磁盘读取中。因此，虽然B树查询查询的次数不比平衡二叉树的次数少，但是相比起磁盘IO速度，内存中比较的耗时就可以忽略不计了。因此，B树更适合作为索引。

• 更加适合做索引的B+树

B+树的关键字全部存放在叶子节点中，非叶子节点用来做索引，而叶子节点中有一个指针指向一下个叶子节点。做这个优化的目的是为了提高区间访问的性能。而正是这个特性决定了B+树更适合用来存储外部数据。

JVM

Minor Gc 和 Full GC 有什么不同呢？

目前主流的垃圾收集器都会采用分代回收算法，因此需要将堆内存分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
新生代 GC（Minor GC）: 指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。
老年代 GC（Major GC/Full GC）: 指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。

什么对象会进入老年代

大对象直接进入老年代
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）
长期存活的对象将进入老年代
既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1. 对象在 Survivor 中每熬过一次 MinorGC, 年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。

对象的引用的分类（四种）

1. 强引用
   以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空 间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

2. 软引用（SoftReference）
   如果一个对象只具有软引用，那就类似于可有可无的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
   软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。

3. 弱引用（WeakReference）
   如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
   弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。

4. 虚引用（PhantomReference）
   “虚引用” 顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。
   虚引用主要用来跟踪对象被垃圾回收的活动。

5. 虚引用与软引用和弱引用的一个区别：
   虚引用必须和引用队列（ReferenceQueue）联合使用。当垃 圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是 否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
   特别注意，在程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速 JVM 对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。

如何判断一个类是无用的类

方法区主要回收的是无用的类，那么如何判断一个类是无用的类的呢？
判定一个常量是否是 “废弃常量” 比较简单，而要判定一个类是否是 “无用的类” 的条件则相对苛刻许多。类需要同时满足下面 3 个条件才能算是 “无用的类” ：

1. 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
2. 加载该类的 ClassLoader 已经被回收。
3. 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述 3 个条件的无用类进行回收，这里说的仅仅是 “可以”，而并不是和对象一样不使用了就会必然被回收。

如何判断一个常量是废弃常量

运行时常量池主要回收的是废弃的常量。那么，我们如何判断一个常量是废弃常量呢？
假如在常量池中存在字符串 “abc”，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 “abc” 就是废弃常量，如果这时发生内存回收的话而且有必要的话，“abc” 就会被系统清理出常量池。
JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。

如何判断对象是否死亡（两种方法）

1. 引用计数法
   给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。
   这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。 所谓对象之间的相互引用问题，假如除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。

2. 可达性分析算法
   这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的。

注意：不可达的对象并非 “非死不可”

即使在可达性分析法中不可达的对象，也并非是 “非死不可” 的，这时候它们暂时处于 “缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；

1. 可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。
2. 被判定为需要执行的对象将会被放在一个队列中进行第二次标记，除非这个对象与引用链上的任何一个对象建立关联，否则就会被真的回收。