Java面试题夺命连环问

如何实现一个ioc容器

1. 配置文件配置包扫码路径
2. 递归包扫描获取.class文件
3. 反射·确定需要 交给IOC管理的类
4. 对需要注入的类进行依赖注入

配置文件中指定需要扫描的包路径

1. 定义一些注解，分别表示访问控制层，业务服务层，数据持久层，依赖注入注解，获取配置文件注解
2. 从配置文件中获取需要扫描的包路径，获取到当前路径下的文件信息以及文件夹信息，我们将当前路径所有.class结尾的文件，添加一个Set集合进行储存
3. 遍历set集合，获取在类上有指定注解的类，并将其交给ioc容器，定义一个安全的map用来储存这些对象
4. 遍历这个ioc容器，获取到每一个类的实例，判断里面是否有依赖其他的类的实例，然后进行递归注入

java类加载器

1. JDK自带有三种类加载器：bootStrap classLoader，ExtClassLoader，AppClassLoader

BootStrapClassLoader是ExtClassLoader的父类加载器，默认负责加载

%java_home%/lib/ext文件夹下的jar包和class类

继承ClassLoader实现自定义类加载器

JAVA中的异常体系

java中的所有异常都来自顶级父类Throwable

Throwable下有两个子类Exception和Error

Error是程序无法处理的错误,一旦出现这个错误，则程序将被停止运行

Exception不会导致程序停止，又分为两个部分RunTimeException运行异常和checkdException检查异常

RunTimeExption常常发生在程序运行过程中，会导致程序当前线程执行失败

CheckedException常常发生在程序编译过程中，会导致程序编译不通过

GC如何判断对象可以被回收

1. 引用计数法：每个对象有一个引用技术属性，新增一个引用时计数器+1，引用释放时-1，计数器为0的时候可以回收
2. 可信达分析法：从GC Roots 开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots 没有任何引用链相链时，则证明此对象是不可用的，那么虚拟机就判断是可以回收对象
3. 引用计数法，可能出行A 引用了B，B又引用了A,这个时候就算他们都不在使用了，但因为相互引用计数器=1，永远无法回收

GC Roots的对象有

1. 虚拟机栈（栈针中的本地变量表）中引用的对象
2. 方法区中类静态属性引用的对象
3. 方法区中常量引用的对象
4. 本地方法栈中JNI（即一般说的NAtive方法）引用对象

可达性算法中的不可达对象 并不是立即死亡的，对象拥有一次自我拯救的机会。对象被系统宣告死亡至少要经历两次标记过程：第一个是经过可达性分析发现没有与GC Roots相连接的引用链，第二次是在由虚拟机自动建立的Finalizer队列中判断是否需要执行finnalize方法

线程的生命周期？线程有几种状态？

1. 线程通常有五种状态 ·创建· 就绪· 运行 ·阻塞 ·死亡

阻塞又分为三种

1. 等待阻塞：运行的线程执行wait方法。该线程会释放占用的所有资源，jvm会把该线程放入等待池中。进入这个状态后，是不能自动灌注的，必须依靠其他线程调研 notify或者notifyAll方法才能被换下，wait是object类的方法
2. 同步阻塞：运行的线程执行sleep或者join方法。或者发出了I/O请求时。JVM会把该线程置为阻塞状态。当sleep状态超时。join等待线程终止或者超时。线程重新转入就绪状态。sleep是Thread类的方法

生命周期的五种状态分别带出哪些操作

1. 新建状态：新创建了一个线程对象
2. 就绪状态：线程对象创建后，其他线程调用了该对象的start方法。该状态的线程位于可运行线程池中，变得可运行。等待获取CPU的使用权
3. 运行状态：就绪状态的线程获取了CPU，执行程序代码
4. 阻塞状态：阻塞状态是线程因为某种原因放弃CPU使用权。暂时停止运行。直到线程进入就绪状态，才有集合转到运行状态。
5. 死亡状态：线程执行完了或者因异常退出了RUN方法，该线程结束生命周

Sleep和wait的区别

1. sleep是Thread类的静态本地方法，wait则是Object类的本地方法。

2. sleep方法不会释放lock，但是wait会释放，而且会加入到等待队列中【

   sleep就是把cpu的执行资格和执行权释放出去，不在运行此线程，当定时时间结束再取回CPU资源，参与CPU的调度，获取到cpu资源后就可以继续运行了。而如果sleep时该线程有锁，那么sleep不会释放这个锁。而是把锁带着进入了冻结状态，也就是说其他需要这个锁线程根本不可能获取到这个锁。也就是说无法执行程序。如果在水面期间其他线程调用了这个线程的interrupt方法，那么这个线程也会抛出interruptexception异常返回，这点wait一样

3. sleep方法不依赖于同步器synchronized，但是wait需要依赖synchronized关键字

4. sleep不需要被唤醒（休眠之后推出阻塞），但是wait需要（不指定时间需要被别人中断）

5. sleep一般用于当前线程休眠，或者轮询暂停操作，wait则多用于多线程之前的通信。

6. sleep会让出cpu执行时间且强制上下文切换，而wait则不一定，wait后可能还是有机会重新竞争到锁继续执行的。

7. yield （）执行后线程直接进入就绪状态，马上释放了cpu执行权，但是依然保留了cpu的执行资格，所以有可能cpu下次进入线程调度还会让这个线程获取执行权继续执行

8. join（）执行后线程进入阻塞状态，列如在线程B中调用线程A的join，那线程B会进入到阻塞队列，直到线程A结束或者中断线程。

3. 低代码框架选型

	若依	芋道	Jeecg
公司内使用现状	芯月牧科使用	支付系统使用	风控项目组使用
团队熟悉度	团队成员对其较熟悉，因为该框架与Java语言紧密集成，对于熟悉Java的团队来说学习曲线较为平缓。	由于是较新的框架，团队成员对其相对不熟悉。需要投入额外的时间和资源来学习和掌握。	团队成员对其有一定了解，但需要进一步熟悉其架构和组件。可以通过培训和文档来提高团队技能。
BUG程度	经过长时间的发展和社区反馈，大部分BUG已经被修复。但仍需注意已知BUG，并持续关注官方发布和社区讨论。	在某些功能上存在已知的BUG，但官方团队积极修复，并且社区活跃度较高，容易获得帮助。	相对较为稳定，但也有一些已知的小BUG。官方团队和社区都会积极解决这些问题。
开源程度	完全开源，意味着任何人都可以查看和修改其源代码。这有助于形成一个活跃的社区，并促进框架的发展和改进。	部分开源（需要交199元），这意味着它的某些部分可能不公开或仅部分开源。这可能会限制社区的贡献和可定制性。	完全开源，并且由于其与Java的紧密集成，有大量的开源社区资源和支持。
封装程度	提供了丰富的组件和功能，易于集成到现有系统中。它也支持各种自定义配置和扩展。	相对轻量级的封装，更多依赖于开发者的能力进行定制和扩展。这需要一定的技能集，但对于经验丰富的开发人员来说可能更具灵活性。	提供了较多的封装和预置功能，这使得它易于使用，特别是对于初学者。但对于高级用户，可能封装较多的功能使其不够灵活。
定制化难度	提供了较多的定制选项，可以通过修改配置或扩展现有组件来满足特定需求。但需要一定的技术背景和对Java的了解。	具有较强的定制化能力，可以通过代码或配置进行深度定制。这为开发者提供了更大的灵活性来满足业务需求。	有一定的定制化能力，但相对有限。对于复杂的业务逻辑或特定需求，可能需要额外的开发工作。
生态成熟度	生态较为成熟，有较多的第三方插件和资源。	有一定的生态支持，但相对有限。	生态较为丰富，有较多的社区支持和资源。
技术优点	1. 完全响应式布局：若依框架具有完全响应式布局，支持电脑、平板、手机等所有主流设备，提供了良好的用户体验。 2. 一键生成功能：若依框架具有一键生成功能，包括控制器、模型、视图、菜单等，大大提高了开发效率。 3. 多数据源支持：若依框架支持多数据源配置，简单配置即可实现切换，方便进行数据管理和扩展。 4. 权限管理：若依框架内置了权限管理功能，支持按钮及数据权限，可自定义部门数据权限，提高了系统的安全性和可管理性。 5. 完善的日志记录体系：若依框架提供了完善的日志记录体系，简单注解即可实现，方便进行系统调试和问题排查。 6. 支持服务监控和数据监控：若依框架支持服务监控和数据监控，可以实时监控系统性能和数据变化，及时发现和解决问题。	1. 轻量级、简单易用：芋道框架设计理念是轻量级、简单易用，让开发者能够快速上手并专注于业务开发。 2. 强大的视图层支持：芋道框架支持多种前端技术栈，如Vue3、Vue2、uni-app等，方便开发者快速构建用户界面。 3. 多终端适配：芋道框架支持多种终端适配，包括PC、手机端和平板等设备，可以实现统一代码库适配不同终端。 4. 丰富的插件和扩展机制：芋道框架提供了丰富的插件和扩展机制，方便开发者进行定制和扩展，满足各种业务需求。 5. 安全性能高：芋道框架采用Spring Security & Token & Redis进行权限认证，支持多终端、多种用户的认证系统，保证了系统的安全性和稳定性。 6. 国际化支持：芋道框架支持国际化，服务端及客户端支持多语言切换，方便进行国际化部署和推广。 7. 框架采用支持SaaS多租户	1. 基于模型驱动理念快速开发：Jeecg框架基于模型驱动理念进行业务架构的快速开发，简化了开发流程并提高了开发效率。同时提供代码生成器，能够一键生成前后端代码和单元测试代码。 2. 集成设计器快速实现流程管理：Jeecg框架集成了流程设计器，可以快速实现工作流的一体化管理，降低了开发人员的工作负担。同时提供了多种组件和插件，方便开发者进行定制和扩展。 3. 高效率开发：使用代码生成器可以一键生成前后端代码、单元测试代码以及Swagger接口文档和Validator参数校验等工具的使用大大提高了开发效率。此外还提供了集成微信小程序、微信公众号、企业微信、钉钉等三方登录的插件和集成支付宝、微信等支付与退款的插件等。 4. 封装组件简单易用：Jeecg框架内部采用分模块设计，代码清晰简单易于维护。同时提供了多种封装组件如代码生成、前后端分离、数据权限管理等,可以快速开发出完整的项目。同时集成了基于Activi的在线流程设计器,实现了工作流的一体化管理,建立了从流程定义、发布到监控的全过程控制,基于Spring MVC的代码自动生成工具和基于业务模型驱动的业务过程设计大大提高了软件开发的效率和标准化等优点。 5. 安全性能高：Jeecg框架采用JWT身份验证和RSA加解密算法来保证系统的安全性,支持SaaS多租户
技术缺点	1. 集成复杂：若依框架虽然提供了丰富的功能和工具，但也导致了集成相对复杂，需要开发者花费一定的时间和精力进行配置和整合。 2. 社区规模有限：若依框架的社区规模相对较小，可能影响到遇到问题时的技术支持和资源获取。 3. 部分功能定制性不足：由于若依框架的功能较为全面，因此在某些特定业务场景下可能缺乏足够的定制性，需要结合其他工具或自行开发实现。	1. 功能相对有限：相对于其他框架，芋道框架的功能可能相对较少，可能无法满足一些复杂业务场景的需求。 2. 社区规模相对较小：尽管芋道框架提供了丰富的插件和扩展机制，但其社区规模相对较小，可能影响到遇到问题时的技术支持和资源获取。 3. 部分技术选型限制：芋道框架在技术选型方面可能有一定的限制，例如只支持Java语言等，这可能影响到跨平台开发和多语言支持的需求。	1. 页面和功能相对固定，不够灵活：由于Jeecg框架采用代码自动生成的方式，其生成的页面和功能相对固定，不够灵活。这可能会限制开发者的自由度和创新性。 2. 某些复杂场景下的定制难度较大：Jeecg框架虽然提供了许多封装好的组件和工具，但在某些复杂场景下，如复杂的业务逻辑、特定的数据校验等，可能需要开发者具备较高的技术能力和经验来进行定制开发。 3. 对新手开发者可能存在学习曲线：虽然Jeecg框架提供了丰富的DEMO和文档，但对于新手开发者来说，由于其代码生成器的存在，可能导致理解框架的原理和内部机制不够深入，需要花费更多的时间和精力进行学习和实践。 4. 跨浏览器兼容性有待提高：虽然Jeecg框架在大部分主流浏览器上表现良好，但在一些较旧的浏览器上可能存在兼容性问题，需要进行额外的适配和测试。 5. 集成第三方服务时可能存在一定的门槛：虽然Jeecg框架集成了许多常见的第三方服务，如微信小程序、微信公众号、企业微信、钉钉等，但在集成一些特定的第三方服务时，可能需要开发者具备相应的技术能力和经验，并进行一定的定制开发工作。
性能优点	性能表现稳定，能够满足大多数应用场景的需求。但在高负载或复杂场景下可能需要额外的优化措施。	性能表现稳定，能够满足大多数应用场景的需求。但在高负载或复杂场景下可能需要额外的优化措施。	性能表现良好，通常能够满足常见的Web应用性能需求。但对于极端负载或复杂业务逻辑，可能需要进一步的优化措施。
性能缺点	1. 数据库性能问题：若依框架在处理大量数据时可能会遇到性能瓶颈，尤其是在没有适当索引或查询优化的情况下。这可能导致系统响应缓慢，影响用户体验。 2. 高并发请求处理能力有限：若依框架在处理高并发请求时可能表现不佳，尤其是在没有负载均衡或集群部署的情况下。这可能导致系统过载，影响服务的稳定性和可用性。	1. 处理大数据量时性能不足：芋道框架在处理大量数据时可能表现出性能不足的问题，尤其是在数据密集型应用中。这可能影响系统的响应速度和吞吐量。 2. 高并发请求处理能力有限：芋道框架在处理高并发请求时可能面临挑战，尤其是在流量较大的场景下。这可能导致系统过载或响应延迟。	1. 在高并发环境下性能表现不佳：由于Jeecg框架的某些设计和实现可能导致在高并发环境下性能下降，这对于需要处理大量请求的场景可能会造成一定的影响。 2. 响应时间较长：在一些情况下，由于网络延迟、服务器负载等原因，Jeecg框架的响应时间可能会较长，影响用户体验。
安全优点	提供了一些基本的安全措施和保护机制，如数据加密、身份验证等。但可能需要额外的安全配置和加固来满足更高级的安全需求	注重安全性，提供了多种安全特性，如数据加密、访问控制和权限管理等。这有助于确保应用的安全性和数据完整性。	安全性能较强，符合常见的安全标准和实践。但仍然需要开发者注意安全最佳实践并在开发过程中实施适当的安全措施。
安全缺点	1. 身份验证和授权机制不够完善：若依框架在身份验证和授权方面可能存在一些安全隐患，例如未经验证的用户访问、权限提升等问题。这可能导致未经授权的用户访问敏感数据或执行特定操作。 2. 输入验证不足：若依框架在输入验证方面可能存在一些不足，这可能导致安全漏洞，如SQL注入、跨站脚本攻击（XSS）等。这些漏洞可能会对系统安全构成威胁。 3. 敏感数据保护不足：若依框架在敏感数据的保护方面可能存在一些不足，如数据加密、密码哈希等方面。这可能导致敏感数据泄露，对用户隐私和系统安全造成威胁。	1. 安全漏洞风险：芋道框架可能存在一些已知的安全漏洞，如未经验证的输入、跨站脚本攻击（XSS）等。这些漏洞可能被利用来攻击系统，导致数据泄露或其他安全问题。 2. 身份验证和授权机制不完善：芋道框架的身份验证和授权机制可能不够强大或灵活，无法有效防止未经授权的访问或操作。这可能导致敏感数据泄露或系统被恶意利用。 3. 加密和数据保护措施不足：芋道框架在数据加密和保护方面可能存在不足，如密码存储不安全、敏感数据未加密等。这可能导致数据泄露或被篡改，对用户隐私和系统安全构成威胁。	1. 存在一些已知的安全漏洞：在某些版本中，Jeecg框架可能存在一些已知的安全漏洞，如SQL注入、跨站脚本攻击等，这些可能会对系统的安全性造成威胁。 2. 身份验证和授权机制不够完善：Jeecg框架的身份验证和授权机制可能不够完善，可能导致未经授权的访问和数据泄露。 3. 加密和数据保护措施不足：在某些情况下，Jeecg框架可能没有足够的数据加密和保护措施，导致敏感数据容易被窃取或篡改。
目录结构	若依框架的目录结构也相对清晰，按照功能模块进行划分，每个模块都有自己的目录和文件。同时，若依框架还支持多模块开发，方便大型项目的构建和管理。	芋道框架的目录结构相对清晰，按照功能模块进行划分，每个模块都有自己的目录和文件。这种目录结构有助于代码的组织和管理，方便开发和维护	Jeecg框架的目录结构相对固定，遵循一定的规范和约定。例如，控制器放在专门的Controller目录下，模型放在Model目录下等。这种目录结构有助于提高代码的可读性和可维护性

4. 租户隔离选型

	DATASOURCE 模式（分库）	SCHEMA 模式（分表）	COLUMN 模式（字段隔离）
优点	（1）性能好，可以横向扩容。可以针对租户的性能需求，配置不同性能的数据库实例。例如，租户A的数据多，用户多，要求性能高，数据库实例的配置可以分配更多的内存、更高频率CPU；租户B的数据少，用户少，性能要求低，数据库实例的配置低一些没关系； （2）数据隔离性好；	（1）成本较低，支持的租户较多； （2）性能够好，当存在性能问题时，迁移到独立数据库实例，程序不需要改动； （3）数据隔离性好； ( 4 ) 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。	（1）成本低，支持的租户多； （2）实现简单，直接使用mybatis plus的TenantLineInnerInterceptor拦 [多租户插件 | MyBatis-Plus](https://www.baomidou.com/pages/aef2f2/#tenantlineinnerinterceptor "多租户插件
缺点	（1）系统升级不方便，需求所有数据库都执行一次表变更的sql。随着租户增加，运维的工作量会越来越多； （2）增加一个租户，需要创建一个新的数据库，增加运维的工作量； （3）增加一个租户时，要插入一些初始化数据，开发、运维之间，要维护一个初始化数据sql文件。生产中，经常会出现由于缺少部分初始化数据，导致新租户异常的情况； （4）运营做数据分析时，不方便；	如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据； 如果需要跨租户统计数据，存在一定困难	（1）数据隔离性差； （2）所有数据存在一起，性能随着数据的增加会变得越来越差；
资源共享度	#### 资源共享度最低	#### 资源共享度中等	#### 资源共享度最高
实现难度	较复杂 需要为每个租户配置独立的数据库实例，涉及较多的资源管理和配置工作。	中等 需要在数据库层面实现表结构的动态创建和管理，相对较简单。	简单 需要在数据查询和存储时进行字段级别的控制，实现起来较为复杂。
性能	由于每个租户的数据存储在独立的数据库实例中，对数据库的并发访问可能会受到影响。	根据不同租户的数据访问模式进行表级别的优化可以提高性能。但表数量的增加可能会对数据库查询性能产生影响。	对特定字段的查询和操作可以优化数据库的查询性能，但可能增加数据处理和存储的复杂性。
计费统计	由于每个租户都有独立的数据存储，计费统计需要针对每个数据库实例进行，可能增加统计的复杂性和工作量。	每个租户的数据表可以独立统计，适用于按租户进行计费和统计的情况。	计费统计与具体实现方式有关，可能需要额外设计统计逻辑，以准确计算每个租户的使用情况。
隔离性	#### 隔离性最高 将不同租户的数据存储在不同的数据库实例中，可以实现数据的完全隔离。每个租户只能访问自己的数据库，保证了数据的安全性和隐私性。	#### 隔离性中等 通过为每个租户创建单独的数据表，可以实现表级别的隔离。不同租户的数据存储在不同的表中，可以控制租户之间的数据访问，但可能存在一些交叉操作的风险。	#### 隔离性最低 只将必要的数据字段提供给租户，保证了敏感数据的隔离。但需要仔细设计数据模型，并确保所有租户所需的数据字段都得到满足。