Java基础与核心知识面试题逐字稿模板

一、Java集合框架问题

1. 了解的Java常用集合有哪些，具体适用场景是什么

"面试官您好，Java集合框架主要包括List、Set、Queue和Map四个核心接口，它们各自有不同的实现类和适用场景。我来具体说说：

List接口主要实现类有ArrayList和LinkedList。ArrayList基于动态数组实现，适合频繁随机访问的场景，比如用户列表、商品列表的快速查询。而LinkedList是基于双向链表的实现，适合频繁在头尾进行增删操作的场景，比如消息队列或浏览历史记录。另外，Vector虽然也是动态数组，但它是线程安全的，不过因为同步开销大，已经被ArrayList配合Collections.synchronizedList()或CopyOnWriteArrayList替代了。

Set接口的常用实现类包括HashSet、LinkedHashSet和TreeSet。HashSet基于哈希表实现，查询效率极高，适合快速去重的场景，比如黑名单管理或唯一ID集合。LinkedHashSet在哈希表基础上增加了链表，可以保持元素的插入顺序，适用于需要记录顺序的去重场景，比如最近访问记录。TreeSet基于红黑树实现，元素自动排序，适合排行榜或需要有序的唯一集合。

Map接口的实现类主要有HashMap、LinkedHashMap、TreeMap和ConcurrentHashMap。HashMap同样是基于哈希表，是键值对存储的首选，适用于缓存或字典等场景。LinkedHashMap结合了哈希表和链表，可以保持插入顺序或实现LRU缓存。TreeMap基于红黑树，按键排序，适合需要范围查询的场景。ConcurrentHashMap是线程安全的实现，适用于高并发环境下的键值存储，比如共享配置或计数器。

Queue接口的实现类包括ArrayDeque和PriorityQueue。ArrayDeque基于数组的双端队列，适合高效的头尾操作，比如滑动窗口算法或工作窃取算法。PriorityQueue实现优先级队列，适合任务调度等场景，比如医院急诊排队。此外，LinkedList也实现了Deque接口，可以同时作为队列和列表使用。

不可变集合（JDK 9+新增）如List.of()、Set.of()和Map.of()，适用于读多写少的线程安全场景，比如配置常量或共享数据结构。

在实际应用中，我们通常遵循'无脑选ArrayList，需高频头尾操作才用LinkedList'的原则；对于需要去重的场景，根据是否需要顺序选择HashSet或LinkedHashSet；对于需要排序的场景则选择TreeSet或TreeMap 。线程安全需求下，优先考虑并发集合而非过时的Vector或Hashtable 。"

2. HashMap的键为何一般不可变

"关于HashMap键的不可变性，我认为这主要与哈希表的工作原理有关。在Java中，HashMap的键对象需要满足两个条件：正确的equals()方法实现 和稳定的hashCode()值。如果键对象是可变的，当它被放入HashMap后，如果其哈希码发生改变，就可能导致后续查找时无法定位到正确的桶位置，从而引发数据丢失或查询失败。

具体来说，当键对象被放入HashMap时，会根据其当前的hashCode()计算存储位置。如果后续键对象被修改，导致hashCode()值变化，但实际存储位置没有更新，那么在调用get(key)时，会根据新计算的hashCode()去查找，但找不到原来存储的值。即使找到同一个桶，由于equals()方法可能因为对象变化而返回false，最终无法获取到正确的值。

因此，为了保证HashMap的正确性，通常建议使用不可变对象作为键。如果必须使用可变对象，需要特别小心确保在放入Map后不修改影响哈希码的属性。例如，String、Integer等包装类都是不可变的，适合作为键；而像ArrayList这样的可变对象则不太适合作为键，除非能确保其内容不会被修改。

在实际项目中，我们经常使用不可变对象作为键，比如在缓存系统中，用不可变的参数对象作为缓存键，确保缓存命中率。"

3. HashMap出现哈希冲突时如何解决

"当HashMap中发生哈希冲突时，也就是不同的键对象计算出相同的hashCode()，但它们的equals()方法返回false，这时Java是如何处理的呢？

根据Java的实现机制，HashMap使用链地址法（Separate Chaining）解决哈希冲突。也就是说，每个桶（bucket）实际上是一个链表，当多个键映射到同一个桶时，这些键值对会以链表形式存储在同一个桶中。在查找时，如果发现哈希冲突，会遍历该链表，通过equals()方法逐一比较键对象，直到找到匹配项。

在JDK 1.8之前，链表是单向的；而从JDK 1.8开始，当链表长度超过8时，链表会转换为红黑树，这样查找时间复杂度从O(n)降为O(log n)，大大提高了查询效率。不过，这种优化只在链表长度超过8且表的总容量超过64时才会生效，以避免对小表造成不必要的开销。

为了减少哈希冲突，Java的HashMap采用了**扰动函数（扰动算法）**对hashCode()进行二次处理，将高位和低位进行异或操作，这样可以更均匀地分布到各个桶中。此外，合理选择负载因子（默认0.75）和初始容量也能有效减少冲突。

在实际应用中，如果业务场景中键的分布可能导致大量哈希冲突，可以考虑自定义哈希函数，或者选择其他数据结构，如使用基于红黑树的TreeMap，但需要注意牺牲插入和删除效率的代价。"

4. HashMap中链表为何要转为红黑树，为何不直接用红黑树实现

"关于HashMap中链表转红黑树的问题，我认为这主要与性能和空间的权衡有关。

首先，链表转红黑树的触发条件是链表长度超过8且表的总容量超过64。这是因为当链表较长时（比如超过8个节点），查找操作的时间复杂度会从O(1)退化为O(n)，影响性能。而红黑树的查找时间复杂度为O(log n)，可以有效提升长链表的查询效率。例如，在用户登录记录等高频查询的场景中，这种优化尤为重要。

其次，不直接使用红黑树的原因有几个方面：一是红黑树的结构比链表复杂，节点需要维护更多的指针（父节点、左右子节点），增加了内存开销。二是对于短链表（比如长度小于8），链表的查找效率可能更高，因为红黑树的查找需要更多的比较操作。三是红黑树的插入和删除操作比链表复杂，需要维护树的平衡，增加了时间开销。

另外，当红黑树的节点数减少到6以下时，会自动转换回链表，这也是为了在数据分布变化时保持最佳性能。例如，在电商系统中，某个商品的购买记录可能在促销期间突然增加，此时链表转换为红黑树可以提升查询效率；而促销结束后，数据量减少，又可以转换回链表，节省内存。

这种设计体现了Java集合框架的自适应优化思想，根据实际数据量和分布动态调整数据结构，以达到性能和空间的最佳平衡。"

5. ArrayList的扩容机制是什么，为何扩容为原容量的1.5倍

"ArrayList的扩容机制是当添加新元素时，如果当前容量不足，会创建一个新数组，将原有元素复制到新数组中，然后将新元素添加进去。这个过程是线程不安全的，所以多线程环境下需要使用Vector或Collections.synchronizedList()。

扩容的具体实现是：新数组的容量是原容量的1.5倍（即原容量乘以3/2），而不是简单的翻倍。这样设计的原因有几个方面：

首先，扩容为1.5倍可以减少扩容次数。如果每次扩容都翻倍，那么添加n个元素时需要log2(n)次扩容；而扩容为1.5倍，需要log(3/2)(n)次扩容，次数更少。例如，当需要从16扩容到32时，如果每次翻倍，需要两次扩容（16→32→64）；而如果每次扩容为1.5倍，只需要一次扩容（16→24→36→54→81），次数更少。

其次，扩容为1.5倍可以平衡时间复杂度。数组的复制操作时间复杂度是O(n)，而扩容后的数组可以容纳更多元素，减少后续扩容的频率。通过数学证明，这种策略使得平均插入操作的时间复杂度保持为O(1)，而不是O(n)。

在实际应用中，如果能够预估数据量，建议在初始化ArrayList时指定合适的容量，避免频繁扩容。例如，在处理大量日志时，可以预先设置较大的容量，减少扩容开销。"

6. 如何理解Java反射，反射在工具类（如Spring）中有哪些应用，Spring的IOC通过反射具体怎么做

"Java反射是一种动态获取和操作类信息的能力，允许在运行时获取类的属性、方法、构造函数等信息，并进行动态调用。反射机制的核心是通过Class类、Method类、Field类等API来实现的。

反射在Spring等框架中的应用非常广泛。例如：

IOC容器：Spring通过反射动态创建和管理Bean。当加载配置文件或扫描包时，Spring会使用反射获取类的构造函数、方法和注解信息，然后根据这些信息实例化Bean并注入依赖。
AOP：Spring AOP通过反射拦截方法调用，实现横切关注点（如日志、事务）的解耦。
数据绑定：Spring MVC使用反射将请求参数映射到控制器方法的参数上。

Spring的IOC容器通过反射实现Bean的创建和依赖注入，具体过程如下：

首先，Spring读取配置文件（如XML或注解），使用反射获取类的定义信息。然后，根据类的构造函数或无参构造器，通过反射动态实例化对象。接着，Spring会查找类中的注入点，如@Autowired、@Inject等注解，使用反射获取对应的属性或方法，并注入其他Bean的引用。最后，Spring可能会调用某些初始化方法，如@PostConstruct，通过反射执行这些方法。

这种反射机制使得Spring能够解耦对象的创建和使用，开发者只需关注业务逻辑，而无需手动管理依赖关系。例如，在电商系统中，订单服务需要依赖用户服务和支付服务，Spring通过反射自动创建这些依赖关系，大大简化了开发流程。

需要注意的是，反射虽然灵活，但性能开销较大，不适合高频调用的场景。因此，Spring等框架通常会在启动时完成反射操作，将结果缓存起来，以减少运行时的性能损耗。"

7. JVM内存结构包含哪些部分

"JVM内存结构主要包括以下几个部分：

堆（Heap）：这是最大的内存区域，用于存储所有对象实例和数组。堆被划分为新生代（Young Generation）和老年代（Old Generation）。新生代又分为Eden区和两个Survivor区（From和To），用于存放新创建的对象；老年代存放生命周期较长的对象。堆的大小可以通过-Xms和-Xmx参数设置。

方法区（Method Area）：从JDK 8开始，方法区被元空间（Metaspace）取代，用于存储类信息、常量、静态变量等数据。元空间使用本地内存（Native Memory），大小由系统内存决定，不再受固定的上限限制。

虚拟机栈（JVM Stack）：每个线程都有一个独立的虚拟机栈，用于存储方法调用的栈帧，包括局部变量表、操作数栈、动态链接和方法出口等信息。栈的大小可以通过-Xss参数设置。

本地方法栈（Native Method Stack）：与虚拟机栈类似，但用于执行本地方法（如JNI调用）。

直接内存（Direct Memory）：通过NIO的ByteBuffer allocateDirect()等方法分配的内存，不经过堆，直接使用本地内存。这部分内存的管理由JVM负责，但受系统内存限制。

此外，JVM还有运行时常量池 （位于方法区/元空间中），存储编译期生成的各种字面量和符号引用；以及线程本地分配缓冲区（TLAB），用于加速对象分配，减少锁竞争。

在实际应用中，理解JVM内存结构对于性能调优非常重要。例如，调整堆大小可以避免频繁GC；调整元空间大小可以防止类加载过多导致的内存溢出；调整栈大小可以避免深递归导致的StackOverflowError。"

8. Java中new一个对象，与内存分配使用相关的实现过程是什么

"在Java中，new一个对象的过程涉及类加载、内存分配和对象初始化三个主要阶段：

第一阶段：类加载。当JVM首次遇到某个类的字节码时，会通过类加载器（如启动类加载器、扩展类加载器、系统类加载器）加载类文件到方法区，解析类信息，并为类变量分配内存并设置默认值。

第二阶段：内存分配。在堆中为对象实例分配内存。JVM采用两种分配方式：指针碰撞（当堆内存规整时，只需移动指针即可分配）和空闲列表法（当堆内存不规整时，维护一个空闲列表来分配内存）。对于小对象，JVM会优先使用线程本地分配缓冲区（TLAB），通过bump-the-pointer机制快速分配，减少锁竞争。只有当对象超过TLAB大小或需要直接分配到老年代时，才会跳过TLAB 。

第三阶段：对象初始化。将对象实例的成员变量设置为默认值（如int为0，对象引用为null），然后执行构造函数，完成对象的初始化操作。

整个过程通过逃逸分析来优化，如果发现对象不会被外部访问，JVM可能会将对象的成员变量直接分配在栈上，而不是堆上，从而提高性能。

在实际应用中，理解对象创建过程有助于优化内存使用。例如，避免频繁创建小对象，减少GC压力；合理设置TLAB大小（通过-XX:TLABSize参数）可以提高多线程环境下的对象分配效率。"

9. new对象时内存不足会发生什么操作

"当new对象时内存不足，JVM会抛出OutOfMemoryError异常。但具体行为取决于内存不足的类型和JVM的配置：

堆内存不足：当Eden区无法分配新对象时，会触发Minor GC。如果Minor GC后仍然无法分配，会触发Full GC。如果Full GC后仍然无法分配，JVM会抛出OutOfMemoryError: Java heap space 。

元空间/方法区不足：当类加载过多导致元空间无法扩展时，会抛出OutOfMemoryError: Metaspace 。

直接内存不足：当通过NIO的ByteBuffer allocateDirect()分配直接内存时，如果内存不足，会抛出OutOfMemoryError: Direct buffer memory 。

栈内存不足：当线程栈帧过大或递归过深导致栈内存不足时，会抛出StackOverflowError，但严格来说这不是new对象时的问题。

此外，如果使用了nothrow版本的new（如new(nothrow)），当内存不足时会返回nullptr而不是抛出异常，但这种情况在Java中不适用，Java的new操作符始终会抛出OutOfMemoryError。

在实际应用中，处理内存不足需要合理设置JVM参数，如-Xmx设置最大堆大小，-XX:MaxMetaspaceSize设置元空间最大大小，以及使用合适的垃圾回收器（如G1适合大内存应用）。此外，避免内存泄漏和不合理的大对象分配也是关键。"

10. Minor GC如何上升到Full GC

"Minor GC和Full GC是JVM垃圾回收的两个不同阶段，它们的触发条件和执行范围有所不同。Minor GC主要回收新生代（Eden和Survivor区），而Full GC会回收整个堆内存（包括老年代和新生代）。

Minor GC上升到Full GC的几种主要情况：

第一种情况是老年代空间不足。当Minor GC后，存活对象需要晋升到老年代，但老年代没有足够空间容纳这些对象时，就会触发Full GC 。例如，在电商系统中，如果用户会话数据大量存活到老年代，而老年代空间不足，就会导致Full GC。

第二种情况是元空间/方法区不足。当类加载、卸载频繁时，元空间可能无法扩展，这时会触发Full GC来回收不再使用的类元数据。

第三种情况是显式调用System.gc()。虽然System.gc()只是一个建议，但多数JVM实现会响应此调用并触发Full GC。不过，JVM可能不会立即执行，而是等待合适时机。

第四种情况是CMS担保失败。当CMS收集器在并发标记阶段发现无法清理足够的内存，导致无法为下一次Minor GC做准备时，会触发Full GC并切换到Serial Old收集器进行垃圾回收。

第五种情况是G1收集器特定条件。当G1收集器的全局并发标记完成后，或者混合垃圾回收的阈值达到时，会触发Full GC。

最后，当大对象直接分配到老年代失败 ，或者直接内存不足时，也会触发Full GC。

在实际应用中，避免Full GC的关键是合理设置新生代大小（通过-Xmn参数），调整Eden与Survivor的比例（默认为8:1:1），以及避免对象过早晋升到老年代。"

11. 如何理解线程安全，Java中线程安全相关案例及保障关键字（synchronized、volatile等）的作用

"线程安全是指多个线程同时访问某个资源时，能够保证资源的一致性和正确性，不会因为线程间的竞争导致数据错误或异常。

Java中常见的线程安全问题包括竞态条件 （Race Condition）、内存可见性问题 和指令重排序。例如，在电商系统中，如果多个线程同时修改库存数量，就可能出现竞态条件，导致库存计算错误。

Java提供的线程安全保障关键字主要有：

synchronized：通过互斥锁保证代码块或方法的原子性，同一时间只有一个线程可以执行被同步的代码。例如，Vector和Collections.synchronizedList()使用synchronized保证线程安全，但性能较差。而ConcurrentHashMap通过分段锁（JDK 8前）或CAS+Node结构（JDK 8后）提高了并发性能。

volatile：保证变量的可见性，即一个线程修改了volatile变量，其他线程能够立即看到新值。同时，volatile变量禁止指令重排序，确保操作顺序。但volatile不保证原子性，例如i++这样的操作仍然需要synchronized或原子类保证。

原子类（如AtomicInteger）：通过CAS（Compare-And-Swap）操作实现无锁的原子更新，适用于简单变量的并发修改。例如，在计数器场景中，使用AtomicInteger比synchronized更高效。

并发集合（如ConcurrentHashMap、CopyOnWriteArrayList）：专为并发环境设计的数据结构，通过更细粒度的锁或写时复制等机制保证线程安全，同时提高并发性能。例如，CopyOnWriteArrayList适用于读多写少的场景，如监听器列表。

在实际应用中，线程安全的保障需要根据具体场景选择合适机制。例如，在高并发的订单系统中，使用ConcurrentHashMap存储订单信息；在需要频繁读取但偶尔写入的配置场景中，使用CopyOnWriteArrayList；而在简单的计数器场景中，使用AtomicInteger比synchronized更高效。"

12. synchronized和ReentrantLock的区别，使用上有何不同

"synchronized和ReentrantLock都是Java中实现线程同步的机制，但它们有以下主要区别：

锁获取方式：synchronized通过语法糖自动获取和释放锁，而ReentrantLock需要显式调用lock()和unlock()方法，通常在finally块中释放锁，避免资源泄漏。

锁类型：synchronized是非公平锁，而ReentrantLock可以通过构造函数参数设置为公平锁。公平锁确保等待时间长的线程优先获取锁，但可能降低吞吐量。

功能扩展：ReentrantLock提供了更丰富的功能，如尝试获取锁（tryLock）、可中断等待（lockInterruptibly）、超时机制（lock with timeout）以及条件变量（Condition）。而synchronized只能实现基本的互斥锁。

性能差异：synchronized在JIT编译优化后性能较好，但锁粒度较粗；ReentrantLock可以通过锁分离等技术实现更细粒度的锁，提高并发性能，但需要更多的代码和管理。

在使用上，synchronized更适合简单同步场景，代码简洁且不易出错。例如，在单例模式中使用双重检查锁定（DCL）时，可以使用synchronized保证线程安全。

ReentrantLock适合复杂的同步场景，需要更多控制的场景。例如，在需要尝试获取锁的场景中，可以使用tryLock()避免死锁；或者在需要设置超时的场景中，可以使用lockInterruptibly()允许线程中断。

需要注意的是，ReentrantLock的使用必须确保在finally块中释放锁，否则可能导致死锁。例如：

try {

lock.lock();

// 临界区代码

} finally {

lock.unlock();

}

在实际应用中，通常优先考虑synchronized，只有在需要ReentrantLock的高级功能时才使用它。例如，在Spring的Bean创建过程中，可能需要更复杂的锁控制，这时ReentrantLock会更合适。"

13. 为何需要公平锁和非公平锁两种锁类型

"公平锁和非公平锁是Java中ReentrantLock提供的两种锁策略，它们的存在是为了平衡等待线程的公平性和系统吞吐量。

公平锁确保等待时间长的线程优先获取锁，这符合现实世界中的排队原则。例如，在银行柜台系统中，先排队的客户应该先被服务。公平锁的优点是避免了饥饿现象，但缺点是可能降低系统吞吐量，因为线程需要等待更长时间才能获取锁。

非公平锁允许新请求的线程插队获取锁，如果锁处于空闲状态，新线程可以立即获取，而不必等待队列中的线程。这提高了系统吞吐量，但可能导致某些线程长期等待。例如，在高并发的订单系统中，非公平锁可以更快地处理新订单请求，提高系统吞吐量。

需要公平锁的场景通常包括：

需要保证线程公平性，避免某些线程长时间无法获取锁。
系统资源有限，需要合理分配资源。
需要预测线程行为，便于调试和测试。

而需要非公平锁的场景通常包括：

高并发系统，追求最大吞吐量。
短时间任务，线程获取锁后很快释放。
锁竞争不激烈，或者线程等待时间较短。

在实际应用中，公平锁和非公平锁的选择取决于具体业务需求。例如，在需要保证用户请求公平处理的场景中，可以使用公平锁；而在需要处理大量瞬时请求的场景中，如秒杀系统，非公平锁可能更合适。

需要注意的是，公平锁并不完全保证线程获取锁的顺序，因为新线程可能在调用lock()时刚好锁释放，从而立即获取锁。此外，公平锁的实现开销更大，需要维护等待队列，因此性能略差。"

14. 是否用过多线程，线程池的拒绝策略有几种，分别作用是什么

"关于是否使用过多线程，我认为这取决于任务类型和系统资源。过多的线程会导致频繁的上下文切换，增加CPU开销，降低系统性能。通常，线程数的设置需要考虑以下因素：

对于CPU密集型任务，线程数通常设置为N+1，其中N是CPU核心数；对于IO密集型任务，线程数可以设置为2N+1，以充分利用IO等待时间。例如，在电商系统中，订单处理通常是CPU密集型，而图片处理可能是IO密集型，需要不同的线程数设置。

Java线程池的拒绝策略主要有四种：

AbortPolicy：默认策略，当任务队列已满且线程数达到maximumPoolSize时，会抛出RejectedExecutionException异常。适用于需要明确知道任务被拒绝的场景。

CallerRunsPolicy：由提交任务的线程执行任务，直到线程池能够处理新任务为止。这会降低新任务的提交速率，避免系统过载。适用于需要平滑处理任务的场景，如后台监控系统。

DiscardPolicy：静默丢弃无法执行的任务，不抛出异常也不通知。适用于任务可以被丢弃的场景，如日志记录系统。

DiscardOldestPolicy：丢弃任务队列中最旧的任务，然后尝试提交新任务。适用于需要保证队列有空间容纳新任务的场景，如实时数据处理系统。

在实际应用中，拒绝策略的选择需要根据任务的重要性和系统容忍度。例如，在关键业务系统中，如支付系统，可能需要使用AbortPolicy，确保异常被及时发现和处理；而在日志系统中，DiscardPolicy可能更合适，因为日志丢失不会影响核心业务。

此外，线程池的参数配置也很重要，包括corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）类型等。例如，使用LinkedBlockingQueue（无界队列）可能导致内存溢出，而使用ArrayBlockingQueue（有界队列）可以避免这个问题，但需要配合合适的拒绝策略。

总之，线程池的使用需要权衡资源利用和任务处理，合理设置参数和拒绝策略，才能保证系统高效稳定运行。"

15. 线上使用线程池时，参数设定、拒绝策略制定有哪些经验

"在线上使用线程池时，参数设定和拒绝策略制定需要根据任务类型和系统资源进行权衡。我总结了几点经验：

参数设定经验：

首先，**核心线程数（corePoolSize）**的设置需要考虑任务类型。对于CPU密集型任务，建议设置为N+1（N为CPU核心数）；对于IO密集型任务，可以设置为2N+1，以充分利用IO等待时间。例如，在电商系统中，订单处理通常是CPU密集型，而图片处理可能是IO密集型，需要不同的核心线程数。

其次，**任务队列（workQueue）**的选择也很重要。常用的队列包括LinkedBlockingQueue（无界队列，适合任务量波动较小的场景）、ArrayBlockingQueue（有界队列，适合任务量波动较大的场景，避免内存溢出）和PriorityBlockingQueue（优先级队列，适合需要优先处理某些任务的场景）。例如，对于需要保证顺序的后台任务，可以使用ArrayBlockingQueue配合DiscardOldestPolicy；对于需要处理优先级任务的场景，如订单支付和退款处理，可以使用PriorityBlockingQueue。

第三，**最大线程数（maximumPoolSize）**的设置需要考虑系统资源和任务特性。通常可以设置为2N，但对于可能有大量短时间任务的场景，可以适当提高。例如，在电商秒杀系统中，可能需要设置更大的maximumPoolSize来应对瞬时高并发。

第四，**空闲线程存活时间（keepAliveTime）**的设置需要考虑任务频率。对于频繁执行的任务，可以设置较短的存活时间，减少资源占用；对于偶尔执行的任务，可以设置较长的存活时间，避免频繁创建和销毁线程。

拒绝策略制定经验：

首先，需要根据任务的重要性和可丢失性选择合适的拒绝策略。例如，对于关键业务任务，如订单支付，应该使用AbortPolicy，确保异常被及时发现和处理；对于非关键任务，如日志记录，可以使用DiscardPolicy静默丢弃；对于需要保证队列有空间的场景，如实时数据处理，可以使用DiscardOldestPolicy丢弃最旧任务。

其次，拒绝策略需要与任务队列类型配合使用。例如，使用有界队列（如ArrayBlockingQueue）时，需要设置拒绝策略；而使用无界队列（如LinkedBlockingQueue）时，可能不需要设置拒绝策略，但需要注意可能的内存溢出问题。

第三，可以自定义拒绝策略，例如记录日志、降级处理或重试机制。例如，在电商系统中，当订单处理线程池满时，可以将任务放入另一个降级处理的队列，或者记录日志供后续分析。

最后，需要监控线程池状态，包括活跃线程数、队列大小、拒绝次数等，以便及时调整参数和策略。例如，通过JMX或监控工具查看线程池状态，了解任务处理情况，为后续优化提供依据。

在实际应用中，我们通常会先进行压力测试，确定系统的瓶颈和最佳参数配置。例如，在电商系统中，通过模拟高并发订单请求，确定核心线程数、队列大小和最大线程数的合理值，然后根据测试结果调整线程池参数和拒绝策略。"

二、MySQL相关问题

1. InnoDB存储引擎与MyISAM引擎的区别

"InnoDB和MyISAM是MySQL的两种主要存储引擎，它们在多个方面有显著区别：

事务支持：InnoDB支持ACID事务，而MyISAM不支持事务。这意味着在InnoDB中，可以通过BEGIN、COMMIT和ROLLBACK等语句管理事务；而在MyISAM中，所有操作都是自动提交的，无法回滚。

锁机制：InnoDB支持行级锁（Row-Level Locking），可以锁定表中的某一行；而MyISAM仅支持表级锁（Table-Level Locking），锁定整个表。这使得InnoDB在高并发写入场景下性能更好，而MyISAM在读多写少的场景下性能更优。

外键约束：InnoDB支持外键约束，可以维护表之间的引用完整性；而MyISAM不支持外键约束。

索引结构：InnoDB使用聚簇索引（Clustered Index），数据和主键索引存储在一起，适合主键查询；而MyISAM使用非聚簇索引，数据和索引分开存储，适合全表扫描。

崩溃恢复：InnoDB有双重写缓冲（Double-Write Buffer）和日志（Redo Log），崩溃后可以恢复数据；而MyISAM在崩溃后可能导致数据损坏，需要修复。

适用场景：InnoDB适合需要事务、外键约束和高并发写入的场景，如电商交易系统；而MyISAM适合读多写少、不需要事务的场景，如日志分析系统。

在实际应用中，InnoDB已成为MySQL的默认存储引擎，因为它更好地支持现代应用的需求，如事务和并发控制。例如，在用户注册场景中，InnoDB可以保证用户名唯一性，避免并发插入导致的重复数据问题；而在报表系统中，MyISAM可能更适合，因为报表通常只读不写。

需要注意的是，从MySQL 8.0开始，MyISAM引擎已经不再作为默认引擎，并且在某些版本中被逐步淘汰。因此，在新项目中，通常推荐使用InnoDB。"

2. COUNT(*)、COUNT(1)、COUNT(某一列)三者的区别，平常常用哪种

"COUNT(*)、COUNT(1)和COUNT(列名)在MySQL中都是用于统计行数的函数，但它们有以下区别：

COUNT(*)：统计表中所有行的数量，包括NULL值和重复值。它的执行计划会扫描所有行，但不会检查具体列的值。

COUNT(1) ：统计表中所有行的数量，与COUNT()功能相同。在MySQL中，COUNT(1)和COUNT()的性能几乎相同，都是O(n)的时间复杂度。

COUNT(列名)：统计指定列非NULL值的行数。如果列中存在NULL值，这些行不会被计入。例如，COUNT(name)会统计name列不为NULL的行数。

在实际应用中，COUNT(*)是最常用的，因为它直观地表示统计所有行。例如，在用户管理系统中，统计总用户数通常使用COUNT(*)。

需要注意的是，当表数据量很大时，直接执行COUNT(*)可能会导致性能问题，因为它需要扫描所有行。此时，可以考虑以下优化：

如果只需要近似值，可以使用SHOW TABLE STATUS或利用InnoDB的系统表空间信息。
如果需要精确值，可以使用分页统计，如SELECT COUNT(*) FROM (SELECT id FROM table LIMIT 1000000) AS tmp。
对于经常需要统计的场景，可以考虑维护一个计数器表，通过触发器或应用层更新计数器。

此外，COUNT(列名)在某些场景下更有意义。例如，统计用户填写了手机号的记录数，可以使用COUNT(mobile)，这样只计算mobile列不为NULL的行数。

在实际项目中，我们通常会根据需求选择合适的COUNT函数。例如，在电商系统中，统计所有订单使用COUNT(*)；统计已支付订单使用COUNT支付状态列。"

3. MySQL默认的事务隔离级别是什么，除默认外还有哪些事务隔离级别

"MySQL默认的事务隔离级别是可重复读（REPEATABLE READ），这是SQL标准定义的四个隔离级别之一，其他级别包括：

读未提交（READ UNCOMMITTED）：允许事务读取其他事务未提交的修改，可能导致脏读。

读已提交（READ COMMITTED）：只允许读取已提交的数据，解决了脏读问题，但可能出现不可重复读。

可重复读（REPEATABLE READ）：保证同一事务中多次读取同样数据结果一致，通过MVCC（多版本并发控制）实现，避免了不可重复读。

可串行化（SERIALIZABLE）：强制事务串行执行，解决了所有并发问题，但性能较差。

在可重复读级别下，InnoDB通过MVCC和间隙锁（Gap Lock）的组合策略，可以避免脏读、不可重复读和幻读。例如，在电商系统中，用户查询购物车时，不会看到其他用户未提交的修改（脏读），也不会看到同一事务中购物车内容的变化（不可重复读），也不会看到其他事务插入的新商品（幻读）。

需要注意的是，MySQL的可重复读级别与SQL标准略有不同。在SQL标准中，可重复读级别仍然可能出现幻读，而InnoDB通过间隙锁解决了这个问题，使得可重复读级别下也能避免幻读。

在实际应用中，读已提交和可重复读是常用的隔离级别。读已提交适合需要看到最新数据的场景，如银行系统；而可重复读适合需要保持事务内数据一致性的场景，如电商订单处理。

只有在需要严格保证数据一致性的场景，才会使用可串行化级别，但通常会导致性能下降，因为事务必须串行执行。

可以通过以下SQL语句查看和修改隔离级别：

SELECT @@TX ISOLATION; -- 查看当前会话的隔离级别

SET GLOBAL TRANSACTION ISOLATION LEVEL 读已提交; -- 修改全局隔离级别

在实际项目中，我们通常会在应用启动时设置合适的隔离级别，或者在特定事务中临时调整。例如，在电商系统的订单创建过程中，可能会临时提高隔离级别，确保库存扣减的准确性。"

4. 可重复读隔离级别的MVCC除对应解决的问题外，还能解决哪些问题

"可重复读隔离级别的MVCC（多版本并发控制）除了解决脏读和不可重复读问题外，还能解决幻读问题，这是InnoDB对SQL标准的扩展。

脏读是指事务读取了其他事务未提交的修改。在可重复读级别下，MVCC通过版本控制，使得事务只能看到已提交的数据版本，从而避免脏读。

不可重复读是指同一事务内多次读取同一数据结果不同。MVCC通过为每个事务创建数据快照，保证事务内多次读取同一数据结果一致。

幻读是指事务读取到了之前查询没有出现的记录。InnoDB通过**间隙锁（Gap Lock）和临键锁（Next-Key Lock）**来防止其他事务在事务执行期间插入或更新间隙中的行，从而避免幻读。

此外，MVCC还能带来以下优势：

读写不阻塞：MVCC允许读操作和写操作并发执行，不需要等待对方完成，提高了系统吞吐量。

历史数据访问：通过设置事务隔离级别或使用特定函数（如SELECT ... FOR UPDATE），可以访问历史版本的数据，便于数据恢复和分析。

减少锁竞争：MVCC通过版本控制，减少了显式锁的使用，降低了锁竞争带来的性能损耗。

在实际应用中，MVCC是InnoDB实现高并发的关键机制。例如，在电商系统中，用户浏览商品时，不会阻塞其他用户下单操作；而订单创建过程中，通过间隙锁保证库存扣减的准确性，避免超卖。

需要注意的是，MVCC在某些情况下可能导致长事务问题。例如，长时间运行的事务会占用旧版本数据，导致数据增长和性能下降。因此，需要合理控制事务长度，避免不必要的长事务。

总之，可重复读隔离级别的MVCC通过版本控制和锁机制的结合，解决了脏读、不可重复读和幻读问题，同时提高了系统的并发性能和数据访问灵活性。"

5. InnoDB的索引结构为何是B+树

"InnoDB选择B+树作为索引结构，主要是因为B+树在范围查询和顺序访问方面具有优势，适合数据库的查询场景。

B+树的结构特点包括：

非叶子节点只存储键值，不存储数据，减少了节点大小，提高了查询效率。例如，在查找用户ID为1000的记录时，只需要在非叶子节点中查找键值，不需要加载完整数据。
所有数据存储在叶子节点，叶子节点形成一个有序链表，支持范围查询和顺序访问。例如，查找用户ID在1000到2000之间的所有记录时，可以快速定位到叶子节点链表中的起始位置，然后顺序访问，减少了磁盘I/O次数。
每个节点可以存储大量键值，减少了树的高度，提高了查询效率。例如，一个3阶的B+树，可以存储多个键值，减少了查找步骤。

与B树相比，B+树更适合数据库索引的原因包括：

B+树的叶子节点形成链表，便于范围查询和排序操作。
B+树的查询路径更统一，所有数据都需要通过叶子节点访问，便于缓存优化。
B+树的非叶子节点更紧凑，提高了磁盘利用率和查询效率。

在实际应用中，B+树的结构使得InnoDB能够高效处理大量数据的查询。例如，在电商系统中，用户ID的索引可以快速定位到特定用户；订单时间的索引可以高效查询最近一周的订单。

此外，InnoDB的聚簇索引（Clustered Index）也是基于B+树实现的，将主键索引和数据存储在一起，提高了主键查询效率。例如，订单表的主键是订单ID，聚簇索引使得通过订单ID查询订单信息非常高效。

需要注意的是，B+树的叶子节点链表是单向的（从JDK 8之前），这在范围查询时可能限制性能。而某些改进的B+树实现（如双向链表）可以进一步提升范围查询效率，但InnoDB的B+树结构相对稳定，改动较少。

总之，InnoDB选择B+树作为索引结构，是为了平衡查询效率、磁盘空间和I/O开销，满足数据库系统对大量数据高效访问的需求。"

6. MySQL出现慢查询时如何处理，若加了索引仍扫描大量行该如何优化

"当MySQL出现慢查询时，首先需要识别慢查询，可以通过设置long_query_time参数（默认10秒）记录慢查询日志。然后，使用EXPLAIN命令分析查询的执行计划，了解索引使用情况和扫描行数。

优化慢查询的常见方法包括：

索引优化：为WHERE、JOIN、ORDER BY等子句涉及的列创建合适的索引。例如，用户登录查询通常需要在用户名和密码字段上创建索引。
**避免SELECT ***：只查询需要的列，减少数据传输和处理开销。例如，查询用户基本信息时，只选择id、name、email等必要字段。
使用覆盖索引：当查询的所有列都在索引中时，数据库可以直接从索引获取数据，无需回表。例如，在订单查询中，如果只需要订单ID和状态，可以在这两个字段上创建联合索引。
分页优化：对于大数据量的查询，使用LIMIT和OFFSET分页，但要注意当OFFSET很大时性能问题。可以考虑基于游标的分页，如SELECT ... WHERE id > last_id LIMIT page_size。
避免全表扫描：通过分析执行计划，确保查询使用了索引。例如，当使用LIKE '%abc'时，会导致全表扫描，无法使用索引。

当加了索引仍扫描大量行时，可能的原因包括：

索引失效：例如，WHERE条件对索引列使用了函数（如WHERE YEAR(date)=2025），或者OR条件跨索引列。
选择性不足：索引列的值分布不均匀，如性别字段只有男女两个值，此时索引可能不会被使用。
联合索引未使用最左前缀：例如，联合索引(a,b,c)，但查询条件只用了b和c，未使用a，导致索引无法有效使用。
数据量过大：即使使用了索引，返回的数据量仍然很大，需要进一步优化。

针对这种情况，可以采取以下措施：

检查索引设计：确保索引列的顺序符合查询条件，且选择性足够高。
拆分查询：将复杂查询拆分为多个简单查询，减少单次查询的数据量。
使用临时表：对于需要多次处理的复杂查询，可以先将结果存入临时表，再进行后续操作。
考虑分库分表：当单表数据量过大时，可以考虑水平分表或分库，降低单次查询的数据量。
使用缓存：对于频繁查询但变化不大的数据，可以使用Redis等缓存减少数据库查询压力。

在实际应用中，慢查询优化需要结合业务场景。例如，在电商系统中，商品搜索可能需要使用全文索引；而订单状态查询可能需要使用覆盖索引减少回表。

总之，MySQL慢查询优化是一个系统工程，需要从索引设计、查询语句、执行计划等多个方面进行分析和调整。"

7. 1000万数据量的大表直接执行表结构修改的UPDATE语句是否合理，若不合理该怎么做

"对于1000万数据量的大表，直接执行表结构修改的UPDATE语句通常是不合理的，因为这会导致以下问题：

锁表时间长：UPDATE操作会锁定表或行，导致其他操作被阻塞，影响系统可用性。
事务日志膨胀：大表UPDATE会产生大量事务日志，可能导致磁盘空间不足或恢复时间过长。
性能下降：单次UPDATE操作需要扫描和修改大量数据，可能导致数据库负载过高，响应时间延长。
可能失败：如果UPDATE过程中出现错误或中断，可能导致数据不一致，需要重新执行或修复。

更合理的做法是分批处理，例如：

使用LIMIT和OFFSET：将UPDATE操作拆分为多个小批量更新，如每次更新10万行，直到完成全部数据。例如：

UPDATE table SET column = value WHERE condition LIMIT 100000;

但需要注意，使用OFFSET可能导致性能问题，可以考虑使用基于游标的分页。
使用临时表：先创建临时表，将数据分批导入临时表并进行更新，最后替换原表。例如：

CREATE TABLE tmp_table LIKE original_table;

INSERT INTO tmp_table SELECT * FROM original_table WHERE ...;

UPDATE tmp_table SET column = value WHERE ...;

RENAME TABLE original_table TO backup_table, tmp_table TO original_table;
使用在线DDL工具：如pt-online-schema-change（Percona Toolkit），它可以在不锁表的情况下修改表结构，适用于大表操作。
结合业务停机窗口：如果可能，选择业务低峰期执行UPDATE操作，减少对用户的影响。
使用触发器或应用层处理：对于需要逐步修改数据的场景，可以在应用层或通过触发器逐步处理。

在实际应用中，大表操作需要谨慎处理，避免影响系统正常运行。例如，在电商系统中，修改用户表的某个字段，可以分批处理，每次更新一定数量的用户，直到完成全部数据。

此外，在UPDATE前最好先备份数据，防止操作失误导致数据丢失。同时，监控数据库性能，确保UPDATE操作不会导致系统过载。

总之，对于大表的表结构修改或数据更新，分批处理是更合理的做法，可以避免锁表、性能下降和数据不一致等问题。"