服务端开发之Java备战秋招9
努力了那么多年,回头一望,几乎全是漫长的挫折和煎熬。对于大多数人的一生来说,顺风顺水只是偶尔,挫折、不堪、焦虑和迷茫才是主旋律。我们登上并非我们所选择的舞台,演出并非我们所选择的剧本。继续加油吧！
目录
1.Java中哪几种创建线程执行任务的方式？
2.为什么不建议使用Excutors创建线程池？
3.线程池有哪几种状态？每种状态分别表示什么？
4.Syschronized和ReentrantLock有哪些不同点？
5.ThreadLocal有哪些应用场景？底层是如何实现的？
6.ReentrantLock分为公平锁和非公平锁，底层是如何实现的？
7.Syschronized的锁升级过程？
8.介绍一下Tomcat？Tomcat中为什么要自定义类加载器？
9.JDK、JRE、JVM之间的区别？
10.hasCode()和equal()的关系？如果两个对象的hashCode值相等，并不一定说明它们相等？
11.String、StringBuilder、Stringbuffer的区别？
12.泛型中extends和super的区别？
13.ConcurrentMap的底层原理和扩容机制？
14.JDK1.7到JDK1.8的HashMap底层发生了哪些变化？
15.说一下HashMap的put，get等方法的底层实现原理？
16.HashMap的扩容机制？涉及到的泊松分布解释下？
17.CopyonWriteArrayList的底层原理？
18.什么是字节码？采用字节码的好处？
19.Java中的异常体系？具体说一下？
20.在Java异常处理机制中什么时候抛出异常？什么时候捕获异常？
21.Java中异常的分类？每个类别下有哪些异常？
22.Java中有哪些类加载器？
23.解释一下类加器的双亲委派机制？
24.JVM中哪些是线程共享区？
25.JVM内存模型？
26.一个对象从加载到JVM，再到被GC清除，都经历什么过程？
27.怎么确定一个对象到底是不是垃圾？
28.JVM中有哪些垃圾回收算法？
29.什么是STW？
30.常用的JVM启动参数有些？项目中怎么排查JVM问题？
31.说说对线程安全的理解？
32.对守护线程的理解？
33.ThreadLocal的底层原理？
34.并发、并行、串行的区别？
35.Java死锁如何避免？
36.线程池的底层工作原理？
37.线程池为什么是先添加队列而不是先创建最大线程？
38.ReentrantLock中lock()方法和tryLock()方法的区别？
39.Syschronized的偏向锁、轻量级锁、重量级锁？
40.谈谈对AQS的理解？AQS如何实现可重入锁？
41.谈谈对IOC的理解？
42.单例Bean和多例Bean？
43.Spring事务的传播机制？
44.Spring事务什么时候会失效？
45.Spring中的Bean是线程安全的吗？
46.Spring中Bean创建的生命周期有哪些步骤？
47.ApplicationContext和BeanFactory有什么区别？
48.Spring中的事务是如何实现的？
49.Spring中什么时候@Transactional注解会失效？
50.Spring容器的启动流程？
51.Spring中用到了哪些设计模式？
52.SpringBoot中常用注解及底原理？
53.SpringBoot启动后做了哪些事？SpringBoot是如何启动Tomcat的？
54.MyBatis的优缺点？MP的优缺点？
55.MyBatis中#{}与${}的区别？
56.了解netty吗？
1.Java中哪几种创建线程执行任务的方式？
Java中可以通过以下四种方式创建线程执行任务：
- 继承Thread类并重写run方法。
- 实现Runnable接口，并将其实例化后传递给Thread类作为任务来执行。
- 使用Callable和Future接口来异步执行任务，并获取任务的返回结果。
- 使用Java 5及以上版本引入的Executors框架下提供的线程池来执行任务。
2.为什么不建议使用Excutors创建线程池？
实际上，并不是不建议使用Executors创建线程池，而是需要根据具体的需求和场景来选择适合的线程池类型。如果我们对线程池的行为和执行细节没有特别要求，Executors提供的预定义线程池通常可以满足我们的需求。
然而，如果我们需要更加精细地控制线程池的行为，例如指定线程池的大小、任务队列、拒绝策略等属性，那么直接使用Executors提供的预定义线程池可能会限制我们的灵活性。在这种情况下，我们需要手动创建ThreadPoolExecutor对象，并显式地设置相关属性，以实现更加自定义化的线程池管理。
此外，需要注意的是，如果我们错误地配置了线程池的大小或者任务队列长度，就可能会导致线程饥饿、死锁等问题，因此在使用线程池时需要仔细考虑其各项参数的设置以避免出现问题。
3.线程池有哪几种状态？每种状态分别表示什么？
线程池通常有以下几种状态：
- RUNNING：表示线程池处于运行状态，接受新任务并处理已有任务。
- SHUTDOWN：表示线程池正在关闭中，不再接受新的任务。但是会处理完已经接受的任务。
- STOP：表示线程池正在强制关闭，不再接受新的任务，并且尝试中断正在执行的任务。
- TIDYING：表示线程池任务已经全部完成，正在进行整理清理工作。
- TERMINATED：表示线程池已经彻底终止，不再可用。
需要注意的是，当线程池处于 SHUTDOWN 或 STOP 状态时，如果还有任务提交，就会抛出 RejectedExecutionException 异常。
4.Syschronized和ReentrantLock有哪些不同点？
Synchronized 和 ReentrantLock 都是用于实现多线程同步的机制，二者的主要不同点如下：
-
可重入性：ReentrantLock 是可重入锁，也就是说，当线程已经获得了该锁并进入了临界区，可以反复地进入临界区而不会被阻塞。而 Synchronized 也是可重入锁。
-
锁的获取方式：Synchronized 是隐式锁，也就是说锁的获取和释放都由 JVM 自动进行，通过 synchronized 关键字修饰的代码块来获取锁。而 ReentrantLock 是显式锁，需要程序员手动获取和释放，通过调用 Lock() 和 Unlock() 方法来获取和释放锁。
-
条件变量：ReentrantLock 提供了 Condition 类，可以使用 await()、signal() 和 signalAll() 方法实现类似 wait()、notify() 和 notifyAll() 的功能，但比前者更加灵活和安全。而 Synchronized 没有提供类似的机制。
-
性能：在低竞争情况下，Synchronized 的效率比较高；而在高竞争情况下，ReentrantLock 的效率比较高，因为它支持公平锁和非公平锁两种模式。
总之，ReentrantLock 是一种更加灵活、可定制化的同步机制，但使用起来相对复杂，需要程序员手动管理锁的获取和释放。而 Synchronized 更加简单易用，但在某些情况下可能会出现死锁或饥饿等问题。
5.ThreadLocal有哪些应用场景？底层是如何实现的？
ThreadLocal主要用于在多线程环境下存储线程本地变量。常见的应用场景包括：
- 线程安全的日期格式化类：每个线程都可以有自己的SimpleDateFormat实例，避免多线程竞争同一个实例造成的线程安全问题。
- 事务管理：不同的线程可以拥有自己的数据库连接，避免多线程竞争同一个连接造成的线程安全问题。
- Web应用中用户身份识别：将当前用户信息存储到ThreadLocal中，在整个请求处理过程中都可以获取到该信息。
底层实现原理是通过为每个线程维护一个独立的变量副本来实现的。当使用ThreadLocal时，每个线程都会创建一个该变量的副本并保存在自己的线程局部变量表中，从而实现了线程隔离。具体实现方式是，ThreadLocal内部维护了一个Map对象，以线程ID作为key，将对应的变量副本存储在value中。这样，每个线程都可以独立访问自己的变量副本，而不会干扰其他线程的数据。另外，由于线程退出时需要清除其对应的变量副本，因此ThreadLocal会在所在线程结束时回收相应的资源。
6.ReentrantLock分为公平锁和非公平锁，底层是如何实现的？
ReentrantLock是一种可重入的互斥锁，可以用来实现线程间互斥访问共享资源。在ReentrantLock中，公平锁和非公平锁是两种不同的获取锁的方式。
公平锁：按照FIFO（先进先出）的顺序获取锁，即先请求锁的线程先获取锁。在多线程竞争下，公平锁会更加公平，但是由于需要维护一个有序队列，因此性能相对较低。
非公平锁：不考虑等待时间，直接尝试获取锁。非公平锁在性能上比公平锁更好，但可能会导致某些线程一直无法获取到锁，从而造成“饥饿”。
底层实现上，ReentrantLock使用了AQS（AbstractQueuedSynchronizer）作为同步器来实现锁的获取和释放。AQS内部维护了一个双向链表，用于保存等待线程队列，当一个线程无法获取锁时，它会被加到等待队列的末尾，并被阻塞。当持有锁的线程释放锁时，AQS会将等待队列中的第一个线程唤醒，使其重新尝试获取锁。在公平锁模式下，等待队列是一个FIFO队列，每个线程都会被加到队列的末尾；而在非公平锁模式下，AQS采用了一种更为高效的方式，在等待队列头结点的锁释放时，直接唤醒下一个等待线程，从而避免了大量线程的阻塞和唤醒操作。
7.Syschronized的锁升级过程？
在Java中，synchronized锁有四种状态：无锁状态、偏向锁状态、轻量级、重量级锁状态。
没有线程的时候无锁，当一个线程第一次进入synchronized代码块时，对象头会设置为偏向锁状态，并将当前线程ID记录在对象头中。如果此后没有其他线程竞争这个锁，那么该线程可以直接获取锁而不需要进行任何同步操作。
如果另一个线程尝试获得这个锁，偏向锁就会升级为轻量级锁。此时，Java虚拟机会在当前线程的线程栈上分配一块空间作为锁记录区域，并将对象头设置为指向该区域的指针。然后，虚拟机会使用CAS（Compare and Swap）操作尝试将对象头修改为指向锁记录区域的指针。如果CAS成功，表示当前线程已经获得了锁，如果失败，则说明有其他线程争夺锁，那么锁就会进一步升级为重量级锁。
重量级锁是最慢的锁状态，它会使得其他线程在尝试获取锁时进入阻塞状态。在重量级锁状态下，Java虚拟机会将等待线程挂起并放到一个等待队列中，直到锁被释放。当一个持有重量级锁的线程释放锁时，Java虚拟机会从等待队列中唤醒一个线程继续执行。
需要注意的是，锁状态的升级是不可逆的，一旦锁升级为更高的状态，就无法降级回去。
8.介绍一下Tomcat？Tomcat中为什么要自定义类加载器？
Tomcat是一个常用的Java Web应用服务器，它实现了Java Servlet和JavaServer Pages (JSP)规范，可以用于开发和部署Web应用程序。以下是Tomcat的一些特点：
-
免费开源：Tomcat是免费开源软件，任何人都可以自由使用、修改和分发。
-
轻量级：Tomcat相对于其他Java应用服务器来说比较轻量，可以更快地启动和关闭。
-
可扩展性：Tomcat支持通过插件添加额外的功能，如安全性、负载均衡和集群等。
-
易于配置：Tomcat提供了易于使用和理解的配置文件和命令行工具，使得管理和配置变得简单。
-
支持多种操作系统：Tomcat可以在Windows、Linux、Mac OS X等多个操作系统上运行。
-
高性能：Tomcat采用了线程池技术和优化的I/O模型，可以处理大量并发请求。
-
安全性：Tomcat提供了基于角色的访问控制机制、SSL/TLS支持、防火墙等安全特性，保障Web应用程序的安全。
总之，Tomcat是一款可靠、灵活、易于使用且高性能的Java Web应用服务器，被广泛应用于企业级Web应用程序的开发和部署中。
Tomcat中自定义类加载器有以下几个原因：
-
支持动态部署：Tomcat允许在运行时动态部署Web应用程序。但是，如果不使用自定义类加载器，则无法卸载WEB应用程序，因为该应用程序的类仍将留在JVM中。
-
隔离类加载：每个Web应用程序都有自己的一组类和库。这些类和库可能与其他Web应用程序中的类和库冲突。使用自定义类加载器可以使每个Web应用程序都有其自己的类加载器，从而实现隔离。
-
安全性：自定义类加载器可用于从受信任的代码（如本地文件系统或数据库）加载类。这确保了Web应用程序只能加载应该加载的类。
总之，自定义类加载器为Tomcat提供了更好的动态部署支持、隔离和安全性。
9.JDK、JRE、JVM之间的区别？
JDK、JRE和JVM是Java平台的三个关键组件，它们之间的区别如下：
-
JDK：JDK全称为Java Development Kit（Java开发工具包），它是开发Java应用程序所必需的工具包，包括Java编译器、Java虚拟机、Java类库等。JDK还提供了一些开发工具，如调试器、性能分析器等，方便开发人员进行Java应用程序的开发、测试和调试。
-
JRE：JRE全称为Java Runtime Environment（Java运行环境），它是运行Java应用程序所必需的软件环境，包括Java虚拟机、Java类库等。JRE不包含Java编译器和其他开发工具，只能用于运行Java应用程序。
-
JVM：JVM全称为Java Virtual Machine（Java虚拟机），它是Java平台的核心组件之一，是Java应用程序运行的基础。JVM负责将字节码转换成本地代码并执行，同时还提供了内存管理、垃圾回收等功能。
总之，JDK是用来开发Java应用程序的工具包，JRE是用来运行Java应用程序的软件环境，JVM是Java应用程序运行的基础平台。在开发Java应用程序时，需要安装JDK；在发布Java应用程序时，只需要保证用户安装了与应用程序所需的Java版本相匹配的JRE即可。
10.hasCode()和equal()的关系？如果两个对象的hashCode值相等，并不一定说明它们相等？
在Java中，HashCode和equals方法都是用于比较对象的方法。
hashCode() 方法返回对象的哈希码，可以理解为将对象转换成一个整数。这个哈希码可以用来快速比较两个对象是否相等。如果两个对象使用equals方法比较返回true，则它们的hashCode值也应该相等；但是，如果两个对象的hashCode值相等，并不一定说明它们相等（即equals方法返回true）。因此，在重写equals方法时，通常也要重写hashCode方法，保证两个方法的一致性。
equals() 方法用于比较两个对象是否相等。当我们需要比较两个对象的内容时，就需要重写equals方法。如果两个对象使用equals方法比较返回true，则它们的hashCode值也应该相等；但是，如果两个对象的hashCode值相等，并不一定说明它们相等。因此，在重写hashCode方法时，需要遵循一些规则，保证两个方法的一致性。
如果两个对象的hashCode值相等，并不一定说明它们相等。
这是因为在Java中，不同的对象可能有相同的hashCode()值，这种情况称为“哈希冲突”或“哈希碰撞”。因为hashCode()方法只是将对象转换成一个整数，且哈希码的范围是有限的（32位），所以在实际应用中，总会存在不同的对象具有相同的哈希码的情况。
因此，在重写equals()方法时，我们需要注意不能仅依赖hashCode()方法来比较两个对象是否相等，而要同时重写hashCode()方法和equals()方法，并遵循它们之间的一致性原则，以确保能够正确地比较两个对象。
11.String、StringBuilder、Stringbuffer的区别？
String、StringBuilder和StringBuffer是Java中常用的字符串类，它们之间的主要区别如下：
-
String类：String是一个不可变的字符串类，即一旦创建就不能被修改。每次对String进行修改，都会生成一个新的String对象，原来的String对象会被垃圾回收器回收。因此，如果需要对字符串进行频繁的修改操作，使用String类会导致大量无用的对象被创建，从而降低效率。
-
StringBuilder类：StringBuilder是一个可变的字符串类，可以进行频繁的修改操作。当需要对字符串进行增加、插入、删除等操作时，建议使用StringBuilder类。StringBuilder类是非线程安全的，在单线程环境下使用效率最高。
-
StringBuffer类：StringBuffer也是一个可变的字符串类，与StringBuilder类相似，但是它是线程安全的。因为它的所有公共方法都是同步的，所以在多线程环境下使用比StringBuilder更为安全。然而，由于同步机制的存在，StringBuffer的效率比StringBuilder低。
总之，如果需要对字符串进行频繁的修改操作，并且在单线程环境下运行，使用StringBuilder会比StringBuffer更有效；如果在多线程环境下运行，或者需要保证线程安全性，使用StringBuffer会比StringBuilder更合适。如果不需要修改字符串，则使用String类即可。
12.泛型中extends和super的区别？
在Java中，泛型通配符可以使用extends和super关键字进行限定。它们的区别如下：
-
extends：表示上界限定，用于指定泛型参数必须是某个类或其子类，或者实现了某个接口。例如，
T extends Number表示泛型参数必须是Number类或其子类。 -
super：表示下界限定，用于指定泛型参数必须是某个类或其父类。例如，
T super Integer表示泛型参数必须是Integer类或其父类。
一般来说，在使用泛型时，如果需要从一个泛型对象中获取数据，则应该使用extends关键字限定泛型类型；如果需要将数据写入到一个泛型对象中，则应该使用super关键字限定泛型类型。
总之，泛型中extends和super关键字的区别在于extends用于限制泛型的上界，即泛型参数必须是某个类或其子类，而super用于限制泛型的下界，即泛型参数必须是某个类或其父类。
13.ConcurrentMap的底层原理和扩容机制？
JDK1.7和JDK1.8中的ConcurrentMap底层实现不同，其中的底层原理和扩容机制也有所区别。
在JDK1.7中，ConcurrentMap的底层实现是分段锁（Segment），每个Segment都是一个独立的哈希表，每个Segment内部采用了ReentrantLock来保证线程安全。当需要修改某个元素时，只需要获取该元素所在的Segment的锁即可，这样可以避免锁的粒度过大导致的性能问题。在JDK1.7中，ConcurrentMap的扩容机制是通过对Segment进行分离来实现的。当某个Segment的元素数量达到一定阈值时，会将该Segment中的元素复制到新的Segment中，从而实现扩容操作。
而在JDK1.8中，ConcurrentMap的底层实现则是基于CAS操作的数组+链表/红黑树结构。ConcurrentHashMap使用了与HashMap类似的数据结构，即数组+链表/红黑树，但是它采用了更加高效的并发策略，并且在多线程环境下，也可以保证高性能和线程安全。在JDK1.8中，ConcurrentMap的扩容机制是通过对整个哈希表进行扩容来实现的。当哈希表中的元素数量达到一定阈值时，就会触发扩容操作，重新计算并分配数组大小，并将旧数组中的元素复制到新数组中，从而提高性能和线程安全性。
总之，JDK1.7和JDK1.8中的ConcurrentMap底层实现有所区别，但都采用了分段锁或CAS操作来保证线程安全，在多线程环境下具有较好的性能表现。同时，在扩容机制方面，JDK1.7是通过对Segment进行分离来实现的，而JDK1.8则是对整个哈希表进行扩容，提高了哈希表的性能。
14.JDK1.7到JDK1.8的HashMap底层发生了哪些变化？
HashMap是Java中非常常用的一个数据结构，它采用了哈希表作为底层数据结构。下面是HashMap的底层原理和扩容机制：
-
底层实现原理：HashMap采用了数组+链表/红黑树的数据结构，将所有的元素存储在一个Node数组中，每个Node对象包含了键值对信息以及下一个节点的引用。当发生哈希冲突时，会使用链表（JDK8之前）或红黑树（JDK8及以后）来解决冲突。
-
扩容机制：当HashMap中的元素数量达到负载因子与数组长度的乘积时，就需要进行扩容操作，默认的负载因子是0.75。扩容会重新计算并分配数组大小，并将旧数组中的元素复制到新数组中。这个过程比较耗时，但是可以减少哈希冲突的概率，提高HashMap的性能。
总之，HashMap的底层数据结构是数组+链表/红黑树，它通过哈希函数将键映射到数组索引上，当发生哈希冲突时，会使用链表（JDK8之前）或红黑树（JDK8及以后）来解决冲突。当元素数量达到一定阈值时，会触发扩容机制，重新计算并分配数组大小，并将旧数组中的元素复制到新数组中，从而提高HashMap的性能。
15.说一下HashMap的put，get等方法的底层实现原理？
HashMap是Java中最常用的集合类之一，它采用了哈希表作为底层数据结构。下面是HashMap中put、get等方法的底层实现原理：
-
put方法：将键值对插入到HashMap中时，会先根据键的hash值和数组长度计算出该元素在数组中的位置。如果该位置上已经存在元素，则会使用链表或红黑树将新的元素添加到该位置的后面。如果该位置上不存在元素，则直接插入元素。当插入的元素数量达到负载因子与数组长度的乘积时，需要进行扩容操作。
-
get方法：通过键获取值时，首先根据键的hash值找到该元素在数组中的位置，然后遍历该位置上的链表或红黑树，找到与该键匹配的元素并返回其对应的值。如果未找到匹配的元素，则返回null。
-
remove方法：通过键删除元素时，首先根据键的hash值找到该元素在数组中的位置，然后遍历该位置上的链表或红黑树，找到与该键匹配的元素并将其删除。如果未找到匹配的元素，则返回null。
总之，HashMap采用了数组+链表/红黑树的数据结构，通过哈希函数将键映射到数组索引上，并使用链表或红黑树来解决哈希冲突。put方法将键值对插入到HashMap中，get方法通过键获取对应的值，remove方法通过键删除元素。在插入、查找和删除元素时，都需要使用哈希函数计算数组索引，并遍历该位置上的链表或红黑树来操作元素。同时，在插入元素数量达到一定阈值时，也需要进行扩容操作。
16.HashMap的扩容机制？涉及到的泊松分布解释下？
HashMap的扩容机制、加载因子、数组长度，链表和红黑树的转换都有其设计理念和考虑因素。
-
扩容机制：HashMap在插入元素时，会检查当前元素数量是否达到阈值（加载因子*数组长度），如果达到则需要进行扩容，即创建一个新的数组，并将原数组中的元素重新散列到新数组中。扩容操作涉及到数组复制和元素重新计算哈希值的过程，因此开销较大。为了避免频繁扩容，HashMap默认的加载因子是0.75，这个值可以在保证空间利用率和时间效率之间做出权衡。
-
数组长度：在扩容时，HashMap的数组长度必须是2的幂次方，这是因为在计算元素在数组中位置的过程中，使用的是位运算而不是取模运算，位运算效率更高。同时，2的幂次方也可以保证哈希函数的分布性，从而减少哈希冲突的概率。
-
链表和红黑树的转换：在JDK8之后，当某个桶中的链表长度超过8时，将会将链表转换为红黑树。这是因为链表的查找效率低于红黑树，当链表长度过长时，查找效率会更低，因此可以将其转换为红黑树来提高查找效率。而当红黑树中的元素数量小于等于6时，则会将红黑树重新转换为链表。这是因为当红黑树中元素数量较小时，链表的查找效率可能会更高。
总之，HashMap的设计考虑了空间利用率、时间效率、哈希函数分布性等多方面因素，扩容机制、加载因子、数组长度、链表和红黑树的转换都是基于这些考虑而设计的。
HashMap的扩容涉及到泊松分布，是因为在哈希表中，元素的插入和删除是一个随机过程，而泊松分布可以用来描述这种随机过程的概率分布。
具体地说，在HashMap中，当元素数量达到负载因子与数组长度的乘积时，就需要进行扩容操作。扩容涉及到将原数组中的元素重新哈希到新数组中的过程，这个过程中可能会出现哈希冲突，因此需要使用链表或红黑树来解决冲突问题。由于元素的插入和删除是随机的，因此可能会导致链表或红黑树的长度出现不均衡的情况，从而影响哈希表的性能。
为了避免这种情况，HashMap在扩容时会采用一种“渐进式扩容”的策略。即在进行扩容前，先对每个桶中的元素进行判断，如果某个桶中的元素数量超过了阈值，则新建一个链表或红黑树来存储这些元素，这样可以避免扩容后出现极端情况的概率。
在这个过程中，泊松分布就被用来计算每个桶中元素的数量分布情况。泊松分布是一种描述单位时间内随机事件发生次数的概率分布，因此可以用来描述每个桶中元素数量的随机性。通过泊松分布计算出每个桶中元素的期望值，再根据期望值来设置阈值，就可以使得扩容后各个桶中元素数量的分布更加均匀，避免了哈希表的性能问题。
总之，HashMap的扩容涉及到泊松分布，是为了保证扩容后各个桶中元素数量的分布更加均匀，从而避免哈希表的性能问题。
17.CopyonWriteArrayList的底层原理？
CopyOnWriteArrayList是Java并发包中提供的一种线程安全的List实现，它的底层原理是基于“写时复制”的思想，可以实现高效、并发的读操作，但写操作开销较大。
在CopyOnWriteArrayList中，读操作可以不加锁进行并发访问。当需要进行写操作时，会先将原数组复制一份，然后在新数组上执行写操作，并将指针指向新数组。由于读操作和写操作并不互斥，因此可以实现高效的并发访问，而且读操作不会阻塞写操作，也不会出现数据不一致的情况。
但这种方式也有其缺点，每次写操作都需要复制整个数组，开销较大，因此适用于读多写少的场景。此外，由于复制操作可能导致内存使用过多，因此在内存有限的情况下，需要谨慎使用。
总之，CopyOnWriteArrayList采用了“写时复制”的策略来保证线程安全，在读多写少的场景下具有很好的性能表现。但由于每次写操作都需要复制整个数组，因此不适用于写入频繁的场景，需要根据实际需求进行选择。
18.什么是字节码？采用字节码的好处？
字节码（Bytecode）是Java虚拟机能够理解的一种指令集，它是Java源代码编译后生成的中间代码。字节码并不是直接运行在操作系统上的机器码，而是通过Java虚拟机来执行。在执行过程中，Java虚拟机会将字节码解释成机器码并执行。
采用字节码的好处有：
-
跨平台性：由于字节码是在Java虚拟机上运行的，因此具有跨平台性，同一份字节码可以在不同的操作系统上运行。
-
安全性：由于字节码不能直接访问底层系统资源，因此可以提高程序的安全性，避免了潜在的安全漏洞。
-
性能优化：由于Java虚拟机可以对字节码进行即时编译和优化，因此可以根据实际情况动态地调整代码执行策略，从而提高程序的性能。
-
灵活性：由于字节码是一种中间形式，开发者可以对其进行修改和优化，从而使程序更加灵活、可扩展。
总之，采用字节码可以提高程序的跨平台性、安全性、性能和灵活性。当然，字节码也有一定的缺点，主要体现在启动速度较慢、占用内存较多等方面，但在大多数情况下，这些缺点是可以通过优化来解决的。
19.Java中的异常体系？具体说一下？
Java的异常体系是Java语言中重要的程序错误处理机制。它分为两大类：Checked Exception和Unchecked Exception。
-
Checked Exception（受检查异常）：在Java中，所有继承自Exception的异常都是Checked Exception。Checked Exception必须在代码中进行捕获或声明抛出异常，否则编译器会报错。常见的Checked Exception包括IOException、SQLException等。
-
Unchecked Exception（非受检查异常）：在Java中，所有继承自RuntimeException的异常都是Unchecked Exception。Unchecked Exception通常发生在运行时，可以不用显式地进行捕获或声明抛出异常。如果程序中出现了Unchecked Exception，那么程序将会崩溃并抛出异常信息。常见的Unchecked Exception包括NullPointerException、IndexOutOfBoundsException等。
Java的异常体系还包括Error，这是一种严重的问题，通常指示JVM本身出现了错误，例如StackOverflowError、OutOfMemoryError等。与Unchecked Exception一样，程序无法恢复并终止执行。
总之，Java的异常体系分为Checked Exception和Unchecked Exception。Checked Exception必须在代码中进行捕获或声明抛出异常，而Unchecked Exception和Error则不需要。在编写程序时，应该根据实际情况来选择合适的异常处理策略，以提高程序的健壮性和可靠性。
20.在Java异常处理机制中什么时候抛出异常？什么时候捕获异常？
在Java的异常处理机制中，当程序出现错误或异常情况时会抛出异常。一般来说，遇到下列情况时需要抛出异常：
-
程序运行时发生了错误，导致无法继续执行。
-
程序遇到非法的输入或参数。
-
程序执行过程中发生了不可预料的错误或异常情况。
-
程序需要告知调用者某个特定条件是否成立（例如在自定义异常类中）。
当抛出异常时，可以使用try-catch语句块来捕获异常，并对异常进行处理。一般来说，需要在以下情况下进行异常处理：
-
需要恢复程序的正常执行流程。
-
需要确保程序不会崩溃。
-
需要记录异常信息以便于程序员进行排错。
在捕获异常时，可以使用try-catch语句块来捕获异常并处理掉。如果没有合适的处理方式，也可以将异常抛出给上层调用者进行处理。在处理异常时，可以通过异常信息来了解具体的错误原因，并采取相应的措施来修复问题，从而提高程序的健壮性和可靠性。
总之，在Java的异常处理机制中，需要根据实际情况来判断何时抛出异常、何时捕获异常，以提高程序的健壮性和可靠性。需要注意的是，在设计自定义异常类时应该遵循Java异常体系的规范，并根据实际情况进行合理的封装和设计。
21.Java中异常的分类？每个类别下有哪些异常？
Java中的异常分为三类：Checked Exception、Unchecked Exception和Error。
- Checked Exception（受检查异常）：所有继承自Exception的异常都是Checked Exception。在编码时，必须显式地处理这些异常，否则将会引起编译错误。
- IOException：用于表示输入输出操作异常，例如文件访问错误、网络连接失败等。
- SQLException：用于表示数据库访问错误。
- ClassNotFoundException：用于表示找不到指定的类。
- IllegalAccessException：用于表示没有权限访问某个方法或字段等。
- NoSuchFieldException：用于表示访问不存在的字段或方法。
- NoSuchMethodException：用于表示调用不存在的方法。
- Unchecked Exception（非受检查异常）：所有继承自RuntimeException的异常都是Unchecked Exception。在编码时，不需要显式地处理这些异常。
- NullPointerException：用于表示试图访问null对象。
- IndexOutOfBoundsException：用于表示数组或集合越界。
- ClassCastException：用于表示类型转换错误。
- IllegalArgumentException：用于表示传递了非法参数。
- UnsupportedOperationException：用于表示不支持的操作。
- ArithmeticException：用于表示算术计算错误等。
- Error：用于表示严重的系统错误，通常需要终止程序运行。
- OutOfMemoryError：用于表示内存不足错误。
- StackOverflowError：用于表示堆栈溢出错误。
- VirtualMachineError：用于表示JVM出现了错误等。
总之，Java中的异常分为Checked Exception、Unchecked Exception和Error三类。了解这些异常类型以及它们的具体含义，有助于我们在编写程序时更好地进行异常处理和调试。
22.Java中有哪些类加载器？
Java中提供了三种类加载器：Bootstrap ClassLoader、Extension ClassLoader和System ClassLoader。
-
Bootstrap ClassLoader：也称为启动类加载器，它负责加载JVM基础核心类库，例如java.lang包下的类。由于这些类是JVM必不可少的部分，因此Bootstrap ClassLoader是在JVM启动时就加载进内存的，并且不需要显式地指定。
-
Extension ClassLoader：也称为扩展类加载器，它负责加载Java的扩展类库（位于JRE/lib/ext目录下的jar文件），并且可以加载应用程序ClassPath路径下的类。Extension ClassLoader是由sun.misc.Launcher$ExtClassLoader实现的，默认是父类加载器是Bootstrap ClassLoader。
-
System ClassLoader：也称为应用程序类加载器，它负责加载应用程序classpath路径下的类。如果没有指定任何类加载器，则默认使用System ClassLoader。System ClassLoader也是由sun.misc.Launcher$AppClassLoader实现的，在运行时可以通过ClassLoader.getSystemClassLoader()方法获取。
除了这三种标准类加载器之外，还可以自定义类加载器来加载特定的类。自定义类加载器可以继承ClassLoader类，并重写findClass()方法来实现自己的类加载逻辑。自定义类加载器常用于实现代码热替换、隔离类加载等功能。
总之，Java中提供了三种标准的类加载器：Bootstrap ClassLoader、Extension ClassLoader和System ClassLoader。了解类加载器的工作原理和分类，有助于我们更好地理解Java程序的运行机制，并且在需要时实现自定义的类加载逻辑。
23.解释一下类加器的双亲委派机制？
类加载器的双亲委派机制是Java类加载器一种重要的工作原理，它指的是当一个类加载器需要加载某个类时，先将请求委托给父类加载器去完成，只有在父类加载器找不到该类的情况下，才由子类加载器去尝试加载。
具体来说，当一个类加载器需要加载某个类时，它会按照以下顺序进行查找：
-
首先，检查自己已经加载的类是否已经包含了该类。如果存在，则直接返回已经加载的类。
-
如果自己没有加载过该类，则将请求委托给自己的父类加载器去进行查找。
-
如果父类加载器也无法加载该类，则将请求再次向上委托，直到Bootstrap ClassLoader为止。
-
如果Bootstrap ClassLoader也无法加载该类，则由当前类加载器自行加载该类。
对于Java虚拟机中的每个类加载器来说，除了Bootstrap ClassLoader之外，都应该有自己的父类加载器。这样就形成了一棵类加载器的层级树。在使用双亲委派机制时，类加载器首先向上委托父类加载器进行查找，因此能够避免同一个类被多个类加载器加载而导致的冲突问题，从而保证了Java应用程序的稳定性和安全性。
双亲委派机制的好处在于：
-
避免重复加载：双亲委派机制可以避免同一个类被多个类加载器重复加载，从而避免了冲突和混乱的问题。这是因为在双亲委派模型中，子类加载器会优先委托父类加载器去加载类，只有当父类加载器无法加载时，子类加载器才会尝试自行加载。
-
提高安全性：由于Java类库都是以根加载器（Bootstrap ClassLoader）为起点，一层一层向下加载的，所以可以保证核心类库的安全性。如果某个类加载器尝试加载Java核心类库中的类，将被父类加载器拦截并抛出ClassNotFoundException异常。
-
简化类加载器：由于每个类加载器都是按照双亲委派机制进行工作的，因此避免了开发人员自行编写复杂的类加载逻辑，使得类加载器的结构更加简单清晰。同时，双亲委派机制也提供了一种有效的类加载器隔离机制，使得不同的类加载器之间相互独立且具有良好的隔离性。
总之，双亲委派机制可以避免重复加载、提高安全性、简化类加载器的结构等，从而提高Java应用程序的稳定性和可靠性。了解双亲委派机制的好处，有助于我们更好地理解Java语言的特性和机制，并编写出更加健壮和安全的Java应用程序。
24.JVM中哪些是线程共享区？
JVM中线程共享区包括：
-
方法区（Method Area）：用于存储类的结构信息、常量池、静态变量以及编译后的代码等。方法区对所有线程都是共享的，因为它包含了JVM加载的所有类信息。
-
堆内存（Heap）：用于存储Java对象实例。堆内存对所有线程都是共享的，因为它存储了所有的Java对象实例。
-
运行时常量池（Runtime Constant Pool）：在Java虚拟机启动时创建，用于存放编译期生成的各种字面量和符号引用。运行时常量池也是线程共享的，因为它存储了所有类的常量池信息。
-
类信息（Class Information）：用于存放Java类的信息，例如类名、父类名、成员变量和方法信息等，这些信息对所有线程都是共享的。
总之，JVM中的方法区、堆内存、运行时常量池和类信息是线程共享区，因为它们存储了Java应用程序的核心元素，对所有线程都具有相同的作用和意义。了解这些线程共享区的作用和特点，有助于我们更好地理解Java虚拟机的内部工作原理，并编写出高效、稳定的Java应用程序。
25.JVM内存模型？
JVM内存模型主要由以下几个部分组成：
-
程序计数器（Program Counter Register）：每个线程都有一个独立的程序计数器，用于记录当前线程所执行的字节码指令地址。因为Java是基于栈的虚拟机，所以程序计数器也被用来记录方法调用和返回的地址。程序计数器对线程来说是私有的，因此不会出现线程安全问题。
-
Java虚拟机栈（Java Virtual Machine Stacks）：每个线程在运行时都会创建一个独立的Java虚拟机栈，用于存储局部变量、操作数栈、动态链接、方法出口等信息。每个方法在执行时都会创建一个栈帧，栈帧包含了该方法的所有运行时数据，例如方法参数、局部变量、返回值等。Java虚拟机栈对线程来说是私有的，因此也不会出现线程安全问题。
-
本地方法栈（Native Method Stack）：用于支持Java虚拟机调用本地方法，在底层实现上与Java虚拟机栈类似。
-
堆（Heap）：用于存储Java对象实例，包括所有的数组和对象。堆是所有线程共享的区域，因此需要考虑线程安全问题。在JVM启动时就会预先分配一块连续的内存空间作为堆空间，当堆空间不足时会自动扩容。
-
方法区（Method Area）：用于存储类的结构信息、常量池、静态变量以及编译后的代码等。方法区对所有线程都是共享的，因为它包含了JVM加载的所有类信息。
-
运行时常量池（Runtime Constant Pool）：在Java虚拟机启动时创建，用于存放编译期生成的各种字面量和符号引用。运行时常量池也是线程共享的，因为它存储了所有类的常量池信息。
除了以上几个部分之外，JVM还有一些其他的辅助区域，例如直接内存（Direct Memory）、元数据区（Metaspace）等。直接内存是JVM利用本地操作系统的内存管理机制所创建的一块内存区域，通常被用来进行高速IO操作。而元数据区则是JDK 8版本之后新增的区域，用于存储类的元数据信息（以前是存储在永久代中的）。
26.一个对象从加载到JVM，再到被GC清除，都经历什么过程？
一个对象从加载到JVM，再到被GC清除，一般经历以下过程：
-
类加载：当Java程序需要使用某个类时，JVM会检查该类是否已经被加载，如果尚未加载，则根据类的全限定名（Fully Qualified Name）进行类加载。类加载过程分为加载、连接和初始化三个阶段，其中连接又包括验证、准备和解析三个子阶段。
-
对象创建：当类被加载后，即可通过new关键字或其他方式创建类的实例对象。对象创建过程包括分配内存空间、初始化对象头以及调用构造函数等步骤。
-
对象使用：对象被创建后，可以通过引用变量进行访问和操作，例如读取或修改对象属性、调用对象方法等操作。
-
引用断开：当对象不再被任何引用变量所引用时，即失去了可达性，这个对象就变得无用了。在这一步，我们通常说对象进入了“死亡”状态。
-
垃圾回收：当JVM检测到某个对象不再被任何引用变量所引用时，就可以将该对象标记为垃圾对象，并将其加入到垃圾回收器中。垃圾回收器在适当的时候会对堆内存中的垃圾对象进行清理，释放内存空间。
在这个过程中，需要注意的是Java中的对象都是动态分配的，而且垃圾回收机制是自动完成的。因此，开发人员不需要手动释放内存，JVM会自动回收无用的对象，从而避免了内存泄漏和野指针等问题。
总之，一个对象从加载到JVM，再到被GC清除，经历了类加载、对象创建、对象使用、引用断开和垃圾回收等多个过程。了解这些过程的特点和工作原理，有助于我们编写高质量、高性能的Java应用程序。
27.怎么确定一个对象到底是不是垃圾？
确定一个对象是否是垃圾通常需要考虑以下几个因素：
-
引用计数：若该对象没有被其他对象引用，则可以判定为垃圾对象。
-
可达性分析：通过检查该对象与根对象（如全局变量或函数）之间是否存在可达路径，来确定该对象是否可以被访问。如果不存在可达路径，则可判定为垃圾对象。
-
循环引用：当两个或多个对象相互引用时，可能会形成循环引用，从而导致它们无法被访问。这种情况下需要使用算法来解决循环引用问题。
-
其他特定语言或框架的规则：某些语言或框架可能有特定的垃圾回收机制和规则，需要遵循这些规则来判定对象是否是垃圾。
综上所述，判断对象是否是垃圾需要综合考虑多个因素，并根据具体情况选择合适的判定方法。
28.JVM中有哪些垃圾回收算法？
JVM中常见的垃圾回收算法包括：
-
标记-清除（Mark and Sweep）算法：标记所有存活对象，清除所有未标记对象，缺点是会产生内存碎片。
-
复制（Copy）算法：将堆分为两个区域，在两个区域之间交替使用，每次只将存活对象复制到下一个区域，然后清除当前区域。优点是不会产生内存碎片，缺点是需要浪费一半的内存空间。
-
标记-整理（Mark and Compact）算法：标记所有存活对象，然后将它们紧凑地移动到一端，将剩余空间清零并释放。优点是不会产生内存碎片，缺点是需要移动大量存活对象，开销较大。
-
分代（Generational）算法：根据对象的存活周期将堆分为多个代，通常将新创建的对象放在年轻代，老龄化的对象放在老年代，不同代采用不同的垃圾回收算法。
-
并发（Concurrent）垃圾回收算法：在程序运行的同时进行垃圾回收，可以减少停顿时间但增加了算法的复杂度和开销。
JVM可以根据应用程序的特点和性能需求选择合适的垃圾回收算法，大多数现代JVM都采用了分代和并发的垃圾回收算法。
29.什么是STW？
STW通常是指“Stop The World”，是一种垃圾回收算法中的一种。在STW期间，应用程序的执行被暂停，以便进行垃圾回收，这意味着在此期间无法响应任何请求或操作。许多编程语言和虚拟机都使用STW算法来管理内存和避免内存泄漏。
30.常用的JVM启动参数有些？项目中怎么排查JVM问题？
以下是一些常用的JVM启动参数：
- -Xmx：设置JVM最大可用内存大小
- -Xms：设置JVM初始内存大小
- -XX:MaxPermSize：设置JVM最大永久代大小
- -XX:+UseG1GC：启用G1垃圾收集器
- -XX:+HeapDumpOnOutOfMemoryError：在发生OutOfMemoryError错误时生成堆转储文件
- -XX:MetaspaceSize：设置元空间大小
- -XX:+PrintGCDetails：打印详细的GC日志信息
- -XX:NewRatio：设置新生代和老年代的比例
- -XX:SurvivorRatio：设置新生代中Eden区和两个Survivor区的比例
- -XX:MaxDirectMemorySize：设置最大直接内存大小
请注意，具体的启动参数可能因操作系统、JVM版本和应用程序而异。
排查JVM问题通常可以分为以下几个步骤：
-
观察系统行为：检查应用程序运行时间、内存占用、线程数等指标，观察应用程序的行为是否异常，确定问题出现的时间段和频率。
-
收集日志信息：收集JVM日志信息，包括GC日志、线程转储、堆栈跟踪等，在日志中搜索异常信息和错误提示。
-
使用诊断工具：使用JVM自带的诊断工具（如jstat、jmap、jstack等）或第三方诊断工具（如VisualVM、JProfiler等）获取应用程序的状态信息，并分析监测数据以找出问题。
-
分析代码：分析应用程序的代码，查找可能引起问题的部分，如内存泄漏、死锁、并发问题等。如果需要，可以进行代码修改或者重构来解决问题。
-
进行实验和测试：在本地或测试环境中进行实验和测试，验证问题是否得到解决，同时监测应用程序的性能和稳定性。
以上是一些基本的排查JVM问题的步骤，但具体情况可能因问题而异，需要根据具体情况进行适当的调整。
31.说说对线程安全的理解？
线程安全是指多个线程访问共享资源时，不会出现数据竞争和不一致的情况。一个线程安全的程序能够正确处理并发访问，并保证最终结果的正确性。为了实现线程安全，通常需要采用同步机制（如锁、信号量等）来控制并发访问，或者使用无锁算法等技术避免竞争。线程安全是多线程编程中的重要概念，它涉及到并发编程的正确性、性能和可靠性等方面。
32.对守护线程的理解？
守护线程（Daemon Thread）是在后台运行的一种特殊类型的线程，它并不会阻止程序的退出。当所有非守护线程都结束时，JVM 会自动关闭守护线程。
具体来说，创建守护线程需要调用setDaemon(true)方法将线程设置为守护线程。一般情况下，守护线程被用于执行一些低优先级的任务，例如垃圾回收、日志记录等。
需要注意的是，守护线程不能访问一些需要确保程序正常运行的资源，例如文件、网络连接等。因此，在创建守护线程时需要考虑这些因素。
33.ThreadLocal的底层原理？
ThreadLocal 是Java中用于创建线程局部变量的工具类。它可以让多个线程并发执行时，每个线程都拥有自己独立的变量副本，互不干扰，从而避免了线程安全问题。
ThreadLocal 的底层原理是通过一个 ThreadLocalMap 来实现的。每个线程都有一个该类实例的副本，当调用 ThreadLocal 的 set() 方法设置某个值时，实际上是将该值存储到当前线程的 ThreadLocalMap 中；当调用 get() 方法获取某个值时，实际上是从当前线程的 ThreadLocalMap 中获取对应的值。
由于每个线程都拥有自己独立的 ThreadLocalMap 副本，因此不同线程之间的数据互不干扰。同时，由于 ThreadLocalMap 采用了弱引用来管理 Key 值，如果线程被回收，则对应的 ThreadLocalMap 中的 Entry 也会被回收，从而避免了内存泄漏的问题。
需要注意的是，使用 ThreadLocal 时要尽量避免内存泄漏的问题。因为 ThreadLocalMap 中的 Entry 对象是由弱引用来管理的，所以如果在业务代码中使用 ThreadLocal 时没有及时清除对应的值，就容易造成内存泄漏。一般来说，使用完毕后需要调用 remove() 方法来清除对应的值，以确保线程局部变量能够被正确地回收。
34.并发、并行、串行的区别？
并发（Concurrency）指的是多个任务在同一时间段内交替进行，通过CPU时间片轮流分配实现并行操作的假象。并发通常用于处理I/O密集型任务，如网络请求、数据库读写等，旨在提高系统吞吐量和响应速度。
并行（Parallelism）则指的是多个任务同时进行，可以利用多核CPU或者分布式计算的方式实现。并行通常用于处理CPU密集型任务，如图像处理、科学计算等，旨在提高计算速度和性能。
串行（Sequential）则指的是一个任务按照指定的顺序逐步执行，直到完成。一般来说，串行是指单线程的执行模式，因为在单线程中只有一个任务可以被执行。
总之， 并发和并行都是处理多个任务的方式，但并发强调的是任务交替执行的方式，而并行则是任务同时执行的方式；而串行则是单线程顺序执行的方式。
35.Java死锁如何避免？
死锁是多线程并发编程中一种非常棘手的问题，它通常发生在两个或更多线程相互等待对方释放资源的情况下。为了避免死锁，可以采取以下几种方式：
-
避免持有多个锁：持有多个锁会增加死锁的可能性，因此要尽量避免。
-
按照固定的顺序获取锁：如果多个线程按照相同的顺序获取锁，就可以减少死锁的风险。
-
设置超时时间：在获取锁的过程中设置超时时间，如果在规定时间内无法获取到锁，则立即放弃，避免长时间等待导致系统崩溃。
-
使用 tryLock() 方法：Java 中的 Lock 接口提供了 tryLock() 方法，可以非阻塞地尝试获取锁，如果获取失败则返回 false，可以根据返回值来决定是否继续执行或者进行其他操作。
-
使用可重入锁（ReentrantLock）：ReentrantLock 可以支持公平锁和非公平锁，公平锁会按照等待时间的先后顺序获取锁，从而避免饥饿现象，减少死锁的风险。
除了以上几种方式之外，还可以使用一些工具来帮助检测死锁，例如jstack命令、VisualVM等。通过这些工具可以查看线程的状态信息，定位死锁的原因，并进行相应的调整和优化。
36.线程池的底层工作原理？
线程池是一种常用的多线程编程技术，它可以帮助我们控制线程的数量、提高程序性能和资源利用率。线程池的基本原理是将任务（Runnable 或 Callable）分配给线程执行，当任务完成后，线程会返回到线程池中等待下一次任务。
线程池的具体工作流程如下：
-
当有任务需要执行时，首先会检查线程池中是否有空闲的线程可用；如果有，则将任务分配给某个空闲线程；如果没有，则进入下一步。
-
线程池会根据预设的参数（例如核心线程数、最大线程数、任务队列长度等）来判断是否需要创建新的线程来执行任务。
-
如果需要创建新的线程，则会根据具体的策略从任务队列中取出任务，并将其分配给新的线程执行。
-
线程在执行完任务后，将结果返回给调用方，并检查是否还有其他任务需要执行；如果有，则继续执行下一个任务，否则将释放线程并返回线程池等待下一次任务。
需要注意的是，线程池的实现方式有很多种，不同的实现方式可能会有一些细节上的差别。例如，不同的线程池实现可能会采用不同的任务队列、线程调度算法、线程池大小调整策略等。因此，在实际应用中，要根据具体的需求和场景选择合适的线程池实现方式。
37.线程池为什么是先添加队列而不是先创建最大线程？
线程池中先添加任务到队列而不是直接创建最大线程的原因有以下几点：
-
资源利用率高：如果先创建最大线程，会占用大量的系统资源，即使这些线程没有实际任务可以执行。而将任务添加到队列中等待执行，可以避免浪费系统资源，提高资源利用率。
-
控制线程数：通过使用任务队列，可以控制线程池中的线程数量，避免由于线程数量过多导致系统负载过高的问题。
-
避免线程频繁创建销毁：如果每次都直接创建最大线程，会导致频繁地创建和销毁线程，增加了资源开销和系统负担，同时也影响了程序性能。
-
更好的灵活性：通过使用任务队列，可以根据实际情况动态调整线程数，从而更好地适应系统的变化和需求。
综上所述，线程池先添加任务到队列而不是直接创建最大线程的做法可以提高系统资源利用率、控制线程数量、避免线程频繁创建销毁等，并且具有更好的灵活性和可扩展性。
38.ReentrantLock中lock()方法和tryLock()方法的区别？
ReentrantLock 中的 lock() 方法和 tryLock() 方法都用于获取锁，但它们之间有以下几个区别：
-
lock() 方法是阻塞式的，即如果锁已经被其他线程持有，则当前线程会被阻塞等待锁的释放；而 tryLock() 方法是非阻塞式的，如果锁已经被其他线程持有，则直接返回 false。
-
lock() 方法在获取锁时会一直尝试获取，直到成功为止，而 tryLock() 方法在获取锁时只会尝试一次，如果获取失败就立即返回。
-
lock() 方法对于重入锁来说是可重入的，即同一个线程可以多次调用 lock() 方法获取锁，而 tryLock() 方法则不支持重入锁。
因此，如果需要在获取锁时进行阻塞等待，或者需要支持重入锁的功能，应该使用 lock() 方法；如果需要快速尝试获取锁并且不需要支持重入锁，则可以使用 tryLock() 方法。需要注意的是，在使用 tryLock() 方法时，一定要根据返回值来判断是否获取到了锁，避免因没有获取到锁而导致程序出现问题。
39.Syschronized的偏向锁、轻量级锁、重量级锁？
在 Java 中，synchronized 关键字可以用于实现线程同步和保护共享资源。在锁的实现中，synchronized 使用了三种不同的锁机制：偏向锁、轻量级锁和重量级锁。
-
偏向锁：偏向锁是一种针对单线程访问同步块场景的优化策略。当只有一个线程访问同步块时，偏向锁会将对象头中的标识位设置为偏向锁，并将线程 ID 记录在对象头中，表示当前线程拥有该对象的锁。这样，在后续访问该对象时，JVM 就可以直接判断该对象是否被当前线程所持有，从而避免了加锁和解锁的过程，提高了程序性能。
-
轻量级锁：如果多个线程竞争同一个对象的锁时，偏向锁就会失效。这时，JVM 会使用轻量级锁来解决竞争问题。轻量级锁采用 CAS（Compare and Swap）操作来获取锁，如果获取成功，则将对象头中的标识位设置为轻量级锁，并将当前线程 ID 记录在锁记录中；如果获取失败，则说明其他线程已经占用该锁，此时 JVM 就会使用自旋等待的方式来等待锁的释放，避免了线程的阻塞和唤醒操作，提高了程序性能。
-
重量级锁：当自旋等待的次数达到一定阈值时，轻量级锁就会升级为重量级锁。重量级锁采用传统的互斥量来实现同步，即在进入临界区前需要先获得锁，并且在退出临界区后需要释放锁。相比于偏向锁和轻量级锁，重量级锁的开销较大，因为它需要进行系统调用和用户态与内核态之间的切换，所以在多线程竞争激烈的场景下使用重量级锁可能会导致性能问题。
总之，偏向锁、轻量级锁和重量级锁都是 Java 中用于实现线程同步和保护共享资源的重要机制，不同的锁机制适用于不同的场景，具体使用时需要根据实际情况进行选择和优化。
40.谈谈对AQS的理解？AQS如何实现可重入锁？
AQS（AbstractQueuedSynchronizer）是 Java 中用于实现同步器的基础类，它提供了一种灵活、可扩展的框架，可以方便地实现各种不同类型的同步器，例如 ReentrantLock、CountDownLatch 和 Semaphore 等。AQS 的核心思想是使用一个等待队列来管理线程状态，通过 CAS 操作来控制线程的互斥和协作。
AQS 的主要功能包括两个方面：
-
定义了一套队列等待机制：在 AQS 中，每个线程需要先获取锁才能进入临界区，如果锁已经被其他线程占用，则必须等待其他线程释放锁后才能获取锁并进入临界区。AQS 使用一个等待队列来管理这些等待线程，这些线程会按照 FIFO（先进先出）的顺序排队等待获取锁，并且可以被随时唤醒以检查是否可以重新尝试获取锁。
-
提供了一组原子操作：在 AQS 中，通过 CAS 操作来更新内部状态变量，从而达到线程同步和协作的目的。AQS 通过定义一组 protected 类型的方法来允许子类重写，例如 tryAcquire()、tryRelease()、tryAcquireShared() 和 tryReleaseShared() 等，子类需要根据具体的锁类型和同步需求来实现这些方法。
对于可重入锁，AQS 实现的方式是，在锁的状态中维护一个 owner 变量，记录当前持有锁的线程；当一个线程再次请求获取锁时，会先检查 owner 是否为当前线程，如果是，则直接返回 true，表示获取锁成功；如果不是，则进入等待队列等待其他线程释放锁。当该线程释放锁时，其他线程可以从等待队列中获取锁，并将 owner 设置为自己，从而实现可重入锁的效果。
总之，AQS 是 Java 并发编程中非常重要的基础类，它提供了一种通用、灵活的同步机制，可以方便地实现各种不同类型的同步器，包括可重入锁、倒计时门闩、信号量等。理解 AQS 的工作原理对于深入理解 Java 并发编程是非常重要的。
CountDownLatch 和 Semaphore 都是 Java 中用于实现线程同步和协作的重要机制，它们在分布式系统、多线程编程和并发控制等领域都有广泛的应用。
- CountDownLatch：
CountDownLatch 是一种简单而强大的同步工具，它可以让一个或多个线程等待其他线程完成操作后再继续执行。CountDownLatch 初始化时会给定一个计数器，当某个线程调用 countDown() 方法减少计数器的值时，其他线程可以通过 await() 方法来等待计数器变为 0，从而达到同步的目的。
CountDownLatch 的主要特点包括：
- 一次性的：一旦计数器被减为 0，就不能重置，也不能再增加计数器的值。
- 等待阻塞：调用 await() 方法会使当前线程进入等待状态，直到计数器变为 0 或者等待超时。
- 线程安全：CountDownLatch 内部使用了锁和条件变量来实现同步和协作，因此是线程安全的。
- 2.Semaphore：
Semaphore 是一种常用的并发控制工具，它可以控制同时访问某个资源的线程数量，并且支持公平和非公平两种策略。Semaphore 初始化时会指定一定数量的许可证（permits），每个线程需要先获取许可证才能进入临界区，当许可证用尽时，其他线程需要等待已有线程释放许可证后才能获取。
Semaphore 的主要特点包括：
- 可重入性：同一个线程可以多次获取许可证，但是每次获取要对应一次释放，否则会导致其他线程无法获取许可证。
- 公平性：如果 Semaphore 的构造函数参数为 true，则表示采用公平策略，即先到先得；如果为 false，则表示采用非公平策略，即获取许可证的顺序可能不遵循先到先得原则。
- 等待阻塞：调用 acquire() 方法会使当前线程进入等待状态，直到获取到许可证或者等待超时。
总之，CountDownLatch 和 Semaphore 都是 Java 中常用的同步工具，它们可以帮助我们实现线程同步、并发控制和协作等功能。需要根据具体的场景和需求来选择合适的同步工具，并进行适当的优化和调整。
41.谈谈对IOC的理解？
IOC（Inversion of Control，控制反转）是一种面向对象编程的设计模式，它的核心思想是将程序中各个组件之间的依赖关系从程序代码中抽离出来，并由容器动态地生成和维护组件之间的依赖关系。
在 IOC 中，应用程序的控制权不再在程序代码中，而是交给了容器。容器负责实例化、配置和管理各个组件对象，并通过反射等机制将这些对象注入到应用程序中。这种方式使得应用程序更加灵活和可扩展，减少了代码的耦合性，提高了程序的可读性和可维护性。
具体来说，IOC 有以下几个主要的特点：
-
依赖注入：IOC 通过依赖注入（Dependency Injection）来管理组件之间的依赖关系。依赖注入可以通过构造函数、属性或方法参数等方式来完成，容器会根据依赖关系自动将需要的组件注入到目标组件中。
-
容器管理：IOC 容器负责创建和管理各个组件对象，同时也负责维护它们之间的依赖关系。容器可以动态地创建和销毁组件，根据需要来修改和调整依赖关系，从而实现组件之间的解耦和灵活性。
-
配置文件：IOC 容器通常需要一个配置文件来描述组件的依赖关系和属性设置。这个配置文件可以是 XML、JSON 或属性文件等格式，容器会根据配置文件中的信息来创建和管理组件对象。
总之，IOC 是一种基于容器的编程模式，它通过将程序中各个组件之间的依赖关系交给容器来管理，实现了组件之间的解耦和灵活性。在 Java 中，Spring 框架就是一个典型的 IOC 容器，它通过依赖注入和配置文件来实现组件之间的管理和协作。理解 IOC 的工作原理对于深入掌握 Spring 框架和 Java EE 编程是非常重要的。
42.单例Bean和多例Bean？
在 Spring 中，Bean 可以分为单例（Singleton）和多例（Prototype）两种类型。
- 单例 Bean：
单例 Bean 是指在整个应用程序中只有一个实例存在的 Bean。当容器第一次加载该 Bean 时，会创建实例并将其缓存到内存中，之后每次获取该 Bean 都会返回同一个实例。如果一个 Bean 的实例在整个应用程序中只需要存在一次，并且该 Bean 可以被多个其他对象共享、频繁使用或者需要保持状态时，通常会选择单例 Bean。例如数据库连接池、线程池、日志工厂等对象都可以作为单例 Bean 实现，这些对象在整个应用程序中只需要存在一次即可满足需求。单例 Bean 的特点包括：
- 线程安全：由于只有一个实例存在，因此不存在多线程竞争的问题。
- 资源占用：单例 Bean 在应用程序启动时就被创建，并且一直保持在内存中，所以会占用一定的系统资源。
- 全局共享：由于是全局共享的，因此需要注意线程安全的问题。
- 多例 Bean：
多例 Bean 是指每次获取时都会创建一个新的实例的 Bean。当容器需要该 Bean 时，会根据定义的配置信息创建一个新的实例，并返回给调用者。如果一个 Bean 的实例必须每次请求时都创建一个新的实例，并且该 Bean 不共享状态或者其状态不受其他对象影响时，通常会选择多例 Bean。例如 HTTP 请求过滤器、Servlet、Controller 等对象都应该作为多例 Bean 实现，因为每个请求都需要创建一个新的实例，并且它们之间的状态不相互影响。多例 Bean 的特点包括：
- 灵活性：多例 Bean 可以根据需要动态创建，避免了一些无效的资源占用。
- 状态隔离：每个实例之间都是相互独立的，因此可以避免状态共享带来的潜在问题。
- 线程安全：由于每个实例都是独立的，因此不存在多线程竞争的问题。
需要注意的是，在使用多例 Bean 时要特别小心，因为如果没有正确管理 Bean 的生命周期，就可能会导致内存泄漏和资源浪费等问题。另外，由于多例 Bean 在每次创建时都需要进行初始化和依赖注入等操作，因此创建多个实例可能会影响应用程序的性能。
总之，单例 Bean 和多例 Bean 都是 Spring 中常用的 Bean 类型，根据具体的需求和场景来选择合适的 Bean 类型，可以有效地提高程序的灵活性和可维护性。
43.Spring事务的传播机制？
Spring 事务的传播机制指在多个事务方法（或事务操作）相互调用时，各自事务如何进行处理和传递的机制。Spring 提供了以下七种事务传播行为：
- REQUIRED：
默认传播机制。如果当前存在事务，则加入该事务并与之共享；否则新建一个事务。这是大多数情况下的默认选择。
- SUPPORTS：
支持当前事务，如果当前存在事务，则加入该事务并与之共享；否则以非事务状态执行。通常用于查询等只读操作。
- MANDATORY：
强制要求当前存在事务，如果不存在事务，则抛出异常。通常用于必须在事务中执行的操作，例如更新、删除等写操作。
- REQUIRES_NEW：
如果当前存在事务，则挂起该事务并创建一个新的事务，同时与当前线程绑定；否则直接创建一个新的事务，与当前线程绑定。
- NOT_SUPPORTED：
以非事务状态执行操作，如果当前存在事务，则挂起该事务并以非事务状态执行；执行结束后恢复原有事务。通常用于与其他系统集成或者需要避免事务干扰的操作。
- NEVER：
以非事务状态执行操作，如果当前存在事务，则抛出异常。通常用于明确指定某个操作不应该运行在事务中的情况。
- NESTED：
如果当前存在事务，则创建一个嵌套事务（子事务），并在嵌套事务中执行操作；否则新建一个事务。嵌套事务是最小的逻辑单位，可以独立于父事务进行提交或回滚。通常用于需要在一个较大的事务中完成多个子任务的情况。
需要注意的是，在使用事务传播机制时需要根据具体的业务需求和场景来选择合适的传播行为，以避免事务处理过程中出现问题或者性能下降等问题。同时，要特别关注事务的隔离级别和回滚策略等设置，确保事务处理的正确性和一致性。
44.Spring事务什么时候会失效？
Spring 事务的失效主要是由于以下几种情况造成的：
- 缺少事务管理器：
在使用 Spring 进行事务管理时，如果没有配置相应的事务管理器，例如没有配置 DataSourceTransactionManager 或者 JpaTransactionManager 等事务管理器，那么事务就无法被正确地管理，从而导致事务失效。
- 事务传播机制设置不当：
事务传播机制指在多个事务方法相互调用时，各自事务如何进行处理和传递的机制。如果设置不当，例如在嵌套事务中使用错误的传播机制（例如 NOT_SUPPORTED 或 NEVER），或者在非事务方法中调用事务方法等，都可能导致事务失效。
- 异常处理不当：
Spring 事务默认会在抛出 RuntimeException 及其子类（例如 DataAccessException）时回滚事务，但是如果该异常被捕获并且未重新抛出或标记为回滚，则事务不会回滚。因此，异常处理不当也可能导致事务失效。
- 数据库操作不当：
在事务中执行数据库操作时，如果没有正确地进行提交和回滚等操作，也可能导致事务失效。例如，在手动管理事务时忘记调用 commit 或 rollback 方法，或者在事务代码块外部修改了数据库的数据等。
总之，Spring 的事务失效通常是由于缺少事务管理器、事务传播机制设置不当、异常处理不当或数据库操作不当等原因造成的。在使用 Spring 进行事务管理时，要注意对每个事务进行正确的配置和处理，以确保事务可以被正确地管理和执行。
45.Spring中的Bean是线程安全的吗？
在 Spring 中，Bean 的线程安全性取决于具体的 Bean 实现和作用域。一般来说，单例（Singleton） Bean 可能存在线程安全问题，而多例（Prototype） Bean 则可以保证线程安全。
- 单例 Bean：
在默认情况下，Spring 的单例 Bean 是线程不安全的，因为它们可能被多个线程同时访问和修改。如果一个单例 Bean 存在可变的状态，例如成员变量或属性值，那么多个线程同时访问和修改该状态可能会导致并发问题和数据不一致等问题。
解决方案有两种：一种是使用 synchronized 或者 ReentrantLock 等锁机制来保护单例 Bean 中的可变状态，从而避免线程安全问题；另一种是将单例 Bean 中的可变状态尽量减少或者消除，避免对状态的修改操作。
- 多例 Bean：
相比较单例 Bean，多例 Bean 更容易实现线程安全，因为每次获取 Bean 时都会创建一个新的实例，并且各个实例之间互不干扰。
需要注意的是，在使用多例 Bean 时要特别小心，因为如果没有正确管理 Bean 的生命周期，就可能会导致内存泄漏和资源浪费等问题。另外，由于多例 Bean 在每次创建时都需要进行初始化和依赖注入等操作，因此创建多个实例可能会影响应用程序的性能。
总之，在 Spring 中，Bean 的线程安全性取决于具体的 Bean 实现和作用域。要确保 Bean 的线程安全性，可以采用适当的锁机制或者将可变状态尽量减少或消除，并且根据具体的需求和场景来选择合适的 Bean 类型和作用域。
46.Spring中Bean创建的生命周期有哪些步骤？
Spring 中 Bean 的创建生命周期主要包括以下步骤：
- 实例化 Bean 对象：
在容器启动时，Spring 会根据配置信息实例化 Bean 对象，并将其保存到容器中。
- 属性注入：
在 Bean 对象被实例化后，Spring 容器将自动执行属性注入操作，即将依赖的其他 Bean 对象注入到该 Bean 中。这个过程可以通过构造方法注入、setter 方法注入或者字段注入等方式完成。
- Aware 回调：
在属性注入完成后，Spring 容器会检查该 Bean 是否实现了一些特定的接口，例如 BeanNameAware、BeanFactoryAware、ApplicationContextAware 等，如果实现了这些接口，则容器会回调相应的方法，让该 Bean 获得对容器的引用和其他相关信息。
- 初始化前回调：
在 Spring 容器将 Bean 注入到目标对象之前，Bean 可以通过实现 InitializingBean 接口或者使用 @PostConstruct 注解等方式来进行初始化操作。这些初始化操作可以包括资源加载、连接数据库等。
- BeanPostProcessor 处理：
当 Bean 初始化前的回调方法执行完成后，Spring 容器会检查是否注册了 BeanPostProcessor 接口的实现类，如果存在，则容器会回调这些处理器的 postProcessBeforeInitialization 方法，在 Bean 初始化前对其进行增强处理。
- 初始化后回调：
在 BeanPostProcessor 处理完成后，Bean 将会调用定义在 InitializingBean 接口中的 afterPropertiesSet 方法或者使用 @PostConstruct 注解等方式进行初始化操作。这些初始化操作可以包括资源加载、连接数据库等。
- 容器销毁 Bean：
当容器关闭时，Spring 会自动调用实现了 DisposableBean 接口的 destroy 方法或者使用 @PreDestroy 注解等方式对 Bean 进行销毁操作，释放占用的资源等。
总之，在 Spring 中，Bean 的生命周期主要包括实例化、属性注入、Aware 回调、初始化前回调、BeanPostProcessor 处理、初始化后回调和容器销毁 Bean 等步骤，每个步骤都提供了不同的扩展点，可以灵活地定制 Bean 的创建和销毁过程。
47.ApplicationContext和BeanFactory有什么区别？
ApplicationContext 和 BeanFactory 都是 Spring 容器的核心组件，它们有以下区别：
- 功能不同：
ApplicationContext 继承自 BeanFactory 接口，提供了更多的高级特性，例如国际化、资源绑定、AOP 等功能，同时也支持事件发布和处理等高级功能。相比之下，BeanFactory 只提供了最基本的 IoC 功能，即通过配置文件或者注解等方式管理和创建 Bean。
- 加载方式不同：
ApplicationContext 是在应用程序启动时就将所有 Bean 预加载到内存中，以便快速获取和使用；而 BeanFactory 的 Bean 则是延迟加载的，只有在使用时才会进行实例化。
- Bean 实例化不同：
在 ApplicationContext 中，Bean 的实例化和初始化是由容器自动完成的，即当一个 Bean 被定义时，容器会立即创建该对象，并且完成 Bean 的初始化工作，包括属性注入、Aware 回调和初始化方法等；而在 BeanFactory 中，Bean 实例化则是懒加载的，只有在获取 Bean 时才会进行实例化操作。
- 性能差异：
由于 ApplicationContext 预加载了所有 Bean，所以在应用程序启动时需要消耗大量的内存和 CPU 资源，因此对于比较大型的应用程序来说，启动速度可能会比较慢。而 BeanFactory 采用懒加载的方式，只有在需要使用 Bean 时才进行实例化，因此占用的资源比较少，启动速度也比较快。
综上所述，ApplicationContext 和 BeanFactory 都是 Spring 容器的核心组件，它们在功能、加载方式、Bean 实例化和性能等方面都存在一定的差异，应根据具体的需求和场景来选择合适的容器类型。如果需要更多的高级特性和功能，则可以选择 ApplicationContext；如果只需要基本的 IoC 功能，则可以选择 BeanFactory。
48.Spring中的事务是如何实现的？
Spring中的事务是基于数据库事务和AOP（面向切面编程）实现的，Spring事务的隔离级别对应的就是数据库的隔离级别。Spring使用@Transactional注解或XML配置来标识应该在事务中执行的方法。当调用带有@Transactional注解或XML配置的方法时，Spring事务管理器会检查当前是否已经存在一个事务，如果不存在，则创建一个新的事务，并在方法执行完成后提交该事务。如果在方法执行期间发生异常，则会回滚该事务并将异常重新抛出。
49.Spring中什么时候@Transactional注解会失效？
在Spring中，@Transactional注解可能会失效的情况包括：
-
在非公共方法上使用@Transactional注解时，因为Spring使用代理机制来管理事务，所以只有通过外部调用才能触发代理，从而启用事务。如果在同一个对象中的两个非公共方法之间相互调用，那么@Transactional注解将失效。
-
如果@Transactional注解被放置在一个静态方法上，它也会失效。这是因为静态方法不依赖于实例化对象，所以无法使用Spring代理。
-
在默认情况下，Spring只会捕获未经检查的异常并回滚事务。如果抛出的异常是已经检查过的异常，则事务不会回滚。为了处理已检查的异常，可以在@Transactional注解中指定对这些异常进行回滚的方式。
-
如果在标记为@Transactional的方法中使用ThreadLocal，则事务也会失效。因为ThreadLocal存储的数据只在线程本地可见，而Spring使用AOP代理机制来管理事务，因此无法在代理中检测到线程本地存储的数据。
-
当事务传播级别设置为Propagation.NOT_SUPPORTED时，事务将被挂起，因此@Transactional注解将不再有效。
50.Spring容器的启动流程？
Spring容器的启动流程如下:
-
加载Spring配置文件或使用基于Java配置类的方式。
-
根据配置文件或Java配置类，创建BeanDefinition对象并将其注册到BeanDefinitionRegistry中。BeanDefinition包含bean的类型、属性和依赖关系等信息。
-
根据注册的BeanDefinition对象，实例化bean并将其存储在IoC容器中。
-
对bean进行依赖注入，将所需的依赖项通过构造函数、setter方法或字段注入到bean中。
-
如果bean实现了Aware接口，则将相应的资源注入到bean中，例如ApplicationContextAware、BeanNameAware等。
-
如果bean实现了InitializingBean接口，则调用afterPropertiesSet()方法进行初始化。
-
如果bean声明了init-method属性，则调用指定的初始化方法进行初始化。
-
如果bean是单例模式，则将其缓存在singletonObjects缓存中。
-
Spring容器启动完成后，如果bean实现了DisposableBean接口，则调用destroy()方法销毁bean。
-
如果bean声明了destroy-method属性，则调用指定的销毁方法进行销毁。
-
如果bean是单例模式，则将其从singletonObjects缓存中移除。
注：以上过程中，第1步和第2步在应用程序启动时执行一次，而第3步到第11步在每次获取Bean时都会执行。
51.Spring中用到了哪些设计模式？
Spring中用到了很多设计模式，下面列举一些主要的设计模式：
-
依赖注入（DI）模式：Spring框架的核心就是依赖注入(DI)模式。该模式通过IoC容器管理对象之间的依赖关系，使得程序具有更好的灵活性和可测试性。
-
工厂模式：Spring使用工厂模式来创建bean。在Spring中，BeanFactory和ApplicationContext充当了工厂的角色，它们负责创建、配置和管理bean实例。
-
单例模式：在Spring中，默认情况下所有的bean都是单例的。这种方式可以提高应用程序的性能，并减少资源浪费。
-
AOP（面向切面编程）模式：AOP允许在不修改原有代码的情况下，通过横切关注点来增强应用程序的功能。Spring AOP采用了代理模式和装饰器模式来实现AOP功能。
-
模板方法模式：Spring框架中的JdbcTemplate、HibernateTemplate等类实现了模板方法模式。这些类定义了一个算法骨架，并将其某些步骤的实现留给具体子类进行实现。
-
观察者模式：Spring框架中的事件机制就是采用观察者模式的一种实现方式。当一个事件发生时，观察者将会收到通知并执行相应的操作。
-
适配器模式：Spring框架中的适配器模式主要用于集成不同的技术和框架。例如，Spring的JMS支持就是通过JmsTemplate和MessageListenerAdapter来实现的。
-
代理模式：Spring AOP采用了代理模式来实现横切关注点的功能。它提供了两种代理方式：JDK动态代理和CGLIB代理。
-
迭代器模式：在Spring框架中，BeanIterator接口充当了迭代器的角色，它可以遍历容器中的所有bean。
总之，Spring框架使用了众多的设计模式，这些模式帮助Spring实现了IoC、AOP、事务管理、异常处理等功能。
52.SpringBoot中常用注解及底原理？
Spring Boot是基于Spring框架的快速开发框架，使用了很多注解来简化配置和代码量，下面列举一些常用的注解及其底层原理：
-
@SpringBootApplication：该注解是Spring Boot应用程序的入口点，它包含了@Configuration、@EnableAutoConfiguration和@ComponentScan三个注解。@Configuration用于定义配置类，@EnableAutoConfiguration用于自动配置Spring Bean，@ComponentScan用于扫描组件。
-
@RestController：用于标记Controller类，并将其声明为RESTful Web服务的入口点。它结合了@Controller和@ResponseBody两个注解的作用，@ResponseBody注解将java对象 以特定的格式(通常都是json)相应给浏览器。底层原理是通过@RequestMapping注解将请求映射到对应的方法上，并将返回值转换为JSON格式返回给客户端。
-
@RequestMapping：用于将HTTP请求映射到特定的处理方法上。底层原理是通过反射机制获取Controller类中的方法，然后根据请求参数匹配调用相应的方法。
-
@Autowired：用于自动装配Bean。底层原理是通过IoC容器查找并注入符合类型要求的Bean实例。
-
@Value：用于获取配置文件中的属性值。底层原理是通过PropertyPlaceholderConfigurer读取配置文件中的属性值，并将其注入到Bean中。
-
@ConfigurationProperties：用于将配置文件中的属性值注入到Java对象中。底层原理是通过Binder将配置文件中的值绑定到目标对象的属性上。
-
@EnableCaching：用于启用缓存功能。底层原理是通过AOP机制，在方法调用前或调用后拦截对缓存的访问，并将结果保存到缓存中。
-
@Transactional：用于声明式事务管理。底层原理是通过AOP机制，在方法调用前或调用后拦截对数据库的访问，并控制事务的开启、提交和回滚等操作。
-
@RequestBody 作用在形参列表上时，用于将前台发送过来固定格式的数据（xml 格式或者 json 等）封装为对应的 JavaBean 对象
总之，Spring Boot使用了很多注解来简化配置和代码量，这些注解的底层原理主要是基于反射、IoC容器、AOP机制等技术实现的。
53.SpringBoot启动后做了哪些事？SpringBoot是如何启动Tomcat的？
SpringBoot启动后会执行以下步骤：
- 加载SpringBoot核心配置类，例如@SpringBootApplication注解的类。
- 扫描应用程序中的组件，例如@Controller、@Service和@Repository注解的类。
- 根据组件创建Bean实例，并通过依赖注入建立它们之间的关系。
- 加载外部配置文件并将其应用到应用程序环境中。
- 启动嵌入式Web服务器，例如Tomcat或Jetty。
- 运行应用程序。
SpringBoot启动Tomcat的流程如下：
- SpringBoot通过读取Maven或Gradle构建文件中的依赖项来获取Tomcat的相关库。
- 在启动时，SpringBoot会自动配置嵌入式Tomcat实例。
- SpringBoot框架会将ServletContextInitializer（例如WebApplicationInitializer）添加到Tomcat容器中。
- Tomcat容器根据ServletContextInitializer的内容启动相应的Web应用程序。
- 应用程序逻辑被加载并运行在Tomcat容器中。
54.MyBatis的优缺点？MP的优缺点？
MyBatis的优点：
- 灵活性高，可以通过XML或注解来进行SQL映射配置；
- 可以与任何基于Java的框架和库集成；
- 提供了强大的动态SQL语句支持。
MyBatis的缺点：
- 配置相对复杂，需要手动编写SQL语句；
- 对于复杂的关联查询和分页查询，需要自己手写SQL语句；
- 开发效率相对较低，需要手工维护SQL语句和数据库映射关系。
Mybatis-plus的优点：
- 提供了更加便捷的CRUD操作，可以通过简单的API调用来快速生成常见的SQL语句；
- 支持代码生成器，可以根据数据表结构自动生成实体类、mapper接口等代码；
- 提供了一些增强功能，如乐观锁、逻辑删除等。
Mybatis-plus的缺点：
- 增加了框架的学习难度，相比于MyBatis本身会有一定的学习成本；
- 可能会存在一些性能损失，因为在生成SQL语句时可能会添加一些额外的条件和语句
55.MyBatis中#{}与${}的区别？
在MyBatis中，#{}和${}都是用来替换SQL语句中的参数的占位符，但是它们在替换过程中存在一些不同：
- #{}：使用#{}时，MyBatis会将传入的参数值加上一个前缀，并把整个参数作为一个占位符放入生成的SQL语句中。同时，MyBatis会为每一个#{}添加一个预编译参数，可以防止SQL注入攻击。
- ${}：使用${}时，MyBatis会直接将传入的参数值替换成SQL语句中对应的位置，即不会加上任何前缀或引号等，直接拼接到SQL语句中。因此，如果使用${}时，需要注意SQL注入攻击的问题。
因此，使用#{}比${}更安全，可以有效地避免SQL注入攻击。但是，在一些特殊情况下，例如动态表名、动态字段等情况下，可能必须使用${}。
56.了解netty吗？
Netty是一个基于Java NIO（New I/O）的客户端/服务器框架，用于开发高性能、高可靠性的网络应用程序。
Netty的主要特点包括：
-
高性能：Netty采用了异步事件驱动的编程模型，可以充分利用多核CPU和操作系统提供的高速缓存来提高网络应用程序的性能。
-
易于使用：Netty封装了Java NIO API，使用起来比原生API更简单，而且提供了许多常用的功能组件，如HTTP和WebSocket协议支持、SSL/TLS加密支持、内存池等等。
-
可扩展性：Netty采用模块化设计，允许用户按需添加或删除组件，从而实现自定义的网络应用程序。
-
支持多种协议：Netty支持各种传输协议，如TCP、UDP、HTTP、WebSocket、SMTP等，而且可以同时处理多种协议的数据交互。
-
易于集成：Netty提供了与Spring、Hibernate等流行框架的集成支持，可以方便地在现有项目中使用。
总之，Netty是一个强大而灵活的网络应用程序框架，适用于构建高性能、高并发的网络服务，如游戏服务器、即时通讯服务器、物联网设备等。