JVM和数据库面试知识点
JVM内存结构
主要有几部分：堆、栈、方法区和程序计数器
堆是JVM中最大的一块内存区域，用于存储对象实例，一般通过new创建的对象都存放在堆中。堆被所有的线程共享，但是它的访问时线程不安全的，通常通过锁的机制来保证线程安全。当堆中的对象超出内存无法回收时，会出现OOM异常。
方法区。(在JDK8之后也叫做元空间)它是被所有线程共享的内存区域，存储了类的结构信息、常量池、静态变量和方法编译后的字节码等。方法区也有可能发生OOM(比如大的静态数据、大的反射和动态代理生成的类)可能消耗大量方法区空间。
程序计数器是每个线程私有的，用于记录当前线程执行的字节码指令的地址。每个线程都有一个独立的线程计数器，用来控制线程的执行流程。
栈主要是用来存储方法调用和局部变量。每个线程运行时都会有一个独立的栈，栈中的每个方法调用，都会创建一个栈帧。栈帧中包含了方法的参数、局部变量和返回值等信息。栈中的数据时线程私有的，不会被其他线程访问的，所以时线程安全的。本地方法栈与虚拟机栈的区别是，虚拟机栈执行的是 Java 方法，本地方法栈执行的是本地方法（Native Method）,其他基本上一致，在 HotSpot 中直接把本地方法栈和虚拟机栈合二为一，这里暂时不做过多叙述。
对象一定分配到堆中嘛
OOM一定会引起JVM退出嘛
java进程占用内存有哪些部分
ava提供了四种类型的引用：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。以下是它们的主要区别：
强引用（Strong Reference）：
这是我们最常用的引用类型。如果一个对象具有强引用，那么它永远不会被垃圾回收器回收，直到这个引用被显式地设置为null或者从集合中移除。
示例：Object obj = new Object(); 这里obj就是一个强引用。
软引用（Soft Reference）：
软引用主要用于实现内存敏感的缓存。如果一个对象只具有软引用，那么在内存充足的情况下，垃圾回收器不会回收它；但是在内存不足时，垃圾回收器会回收这些对象以释放内存。
软引用可以和SoftReference类一起使用，通常用于缓存场景。
示例：SoftReference softRef = new SoftReference<>(obj); 这里softRef就是一个软引用。
弱引用（Weak Reference）：
弱引用比软引用的生存期更短，因为弱引用所指向的对象只能存活到下一次垃圾回收发生之前。当垃圾回收器工作时，无论内存是否充足，都会回收只被弱引用指向的对象。
弱引用可以和WeakReference类一起使用，适用于创建临时的缓存或者引用那些不需要强引用的对象。
示例：WeakReference weakRef = new WeakReference<>(obj); 这里weakRef就是一个弱引用。
虚引用（Phantom Reference）：
虚引用是最弱的一种引用类型。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获取一个对象的实例。
虚引用的主要作用是在对象被垃圾回收器回收时收到一个系统通知。
虚引用需要和PhantomReference类一起使用，并且必须和引用队列（ReferenceQueue）联合使用。
示例：
PhantomReference phantomRef = new PhantomReference<>(obj, refQueue);
这里phantomRef就是一个虚引用。
常见的垃圾回收器
可以打破双亲委派机制嘛
JVM中完整的GC流程
指针碰撞：—前提：内存空间是连续的
维护一个指向空闲内存块的指针，管理和分配内存空间；
分配内存时，指针会向前移动，指向下一个可用的内存块------不需要额外的数据结构来跟踪可以内存块；
是否内存时，指针会向后移动；
为什么适用元空间替代了永久代
永久代是JVM内存是有上限的，而元空间是存储本地内存里，内存上限比较大。避免频繁出现OOM问题。
永久代对象是通过Full GC进行内存清理，元空间是由操作系统内存管理机制处理，简化FullGC，提高性能
加密后的数据如何支持模糊查询
常见的索引数据结构个区别：二叉树、红黑树、B+树、B树；区别：树的高度影响获取数据的性能(每一个树节点都是一次磁盘的I/O)
在MySQL中，当查询语句中对索引列使用某些函数时，确实可能导致索引失效，迫使数据库执行全表扫描。这是因为函数应用于列值后，数据库无法直接利用索引中存储的排列信息。
什么时候索引失效会提升效率
索引失效在某些特定情况下可能会提升查询效率，这听起来可能有些反直觉，但在特定条件下是可能发生的。以下是一些索引失效可能提升效率的情况：
全表扫描更快：
对于小表或结果集非常小的查询，全表扫描可能比使用索引更快，因为索引需要额外的查找和排序开销。
索引选择性不高：
如果索引的选择性不高（即索引列中重复值很多），使用索引可能不会显著减少扫描的行数，优化器可能会选择全表扫描。
索引维护开销：
对于写入操作频繁的表，索引需要频繁更新，这会带来额外的开销。在某些情况下，禁用索引可能减少维护开销，提高写入效率。
复杂的索引结构：
某些复杂的查询条件可能使得索引的查找效率降低，优化器可能会评估使用索引的成本高于全表扫描。
数据分布不均：
如果数据分布极不均匀，导致索引树的某些部分非常深，查询优化器可能认为使用索引不如全表扫描高效。
查询条件导致索引分裂：
某些查询条件可能导致索引分裂，产生大量的内部碎片，影响索引性能，此时全表扫描可能更高效。
索引列上的函数操作：
对索引列进行函数操作可能会导致索引失效，但如果这个函数操作使得查询条件更加严格，减少了结果集，那么全表扫描可能会更快。
JOIN操作中的索引失效：
在某些JOIN操作中，如果JOIN条件复杂或者参与JOIN的表数据量差异很大，索引失效可能因为减少了不必要的JOIN操作而提升效率。
强制索引：
有时候，数据库优化器选择的索引并不是最优的，通过强制使用某个索引（即使它失效了），可能会因为减少了优化器的计算开销而提升效率。
缓存影响：
如果查询的数据已经被缓存在内存中，即使索引失效，全表扫描也可能因为直接从缓存中读取数据而变得高效。
需要注意的是，这些情况并不常见，通常索引是用来提高查询效率的。在实际应用中，应当通过分析和测试来确定是否应该使用索引，以及如何设计索引以达到最佳性能。数据库优化器通常会自动做出这些决策，但有时也需要数据库管理员或开发者进行手动调优。
一条SQL的执行流程
- 连接器（Connection Phase）
首先，客户端与MySQL服务器建立连接，这一阶段由连接器负责处理，包括进行身份验证和权限确认等- 查询缓存（Query Cache） MySQL会检查查询缓存，如果所需查询的结果已经存在于缓存中，便直接返回缓存结果，从而省略后续的查询过程。查询缓存可以提高查询效率，特别是对于重复执行的查询。
- 解析器和预处理器（Parser and Preprocessor） 当查询未命中缓存时，MySQL会运用解析器和预处理器对查询语句进行解析，验证语法正确性，并将查询语句转换为内部数据结构。
- 优化器（Optimizer） MySQL优化器根据查询语句的结构、表的统计信息等因素，生成多个可能的执行计划，并通过成本估算器挑选出最优的执行计划。
- 执行器（Executor） 执行器按照优化器选定的执行计划，调用存储引擎的API来执行查询，获取所需数据。
- 存储引擎（Storage Engine） 存储引擎负责实际的数据存储和检索，根据执行器的请求，读取或写入数据。
- 返回结果给执行器
