如何实现一个ioc容器
- 配置文件配置包扫码路径
- 递归包扫描获取.class文件
- 反射·确定需要 交给IOC管理的类
- 对需要注入的类进行依赖注入
配置文件中指定需要扫描的包路径
- 定义一些注解,分别表示访问控制层,业务服务层,数据持久层,依赖注入注解,获取配置文件注解
- 从配置文件中获取需要扫描的包路径,获取到当前路径下的文件信息以及文件夹信息,我们将当前路径所有.class结尾的文件,添加一个Set集合进行储存
- 遍历set集合,获取在类上有指定注解的类,并将其交给ioc容器,定义一个安全的map用来储存这些对象
- 遍历这个ioc容器,获取到每一个类的实例,判断里面是否有依赖其他的类的实例,然后进行递归注入
java类加载器
- 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,计数器为0的时候可以回收
- 可信达分析法:从GC Roots 开始向下搜索,搜索所走过的路径称为引用链。当一个对象到GC Roots 没有任何引用链相链时,则证明此对象是不可用的,那么虚拟机就判断是可以回收对象
- 引用计数法,可能出行A 引用了B,B又引用了A,这个时候就算他们都不在使用了,但因为相互引用计数器=1,永远无法回收
GC Roots的对象有
- 虚拟机栈(栈针中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI(即一般说的NAtive方法)引用对象
可达性算法中的不可达对象 并不是立即死亡的,对象拥有一次自我拯救的机会。对象被系统宣告死亡至少要经历两次标记过程:第一个是经过可达性分析发现没有与GC Roots相连接的引用链,第二次是在由虚拟机自动建立的Finalizer队列中判断是否需要执行finnalize方法
线程的生命周期?线程有几种状态?
- 线程通常有五种状态 ·创建· 就绪· 运行 ·阻塞 ·死亡
阻塞又分为三种
- 等待阻塞:运行的线程执行wait方法。该线程会释放占用的所有资源,jvm会把该线程放入等待池中。进入这个状态后,是不能自动灌注的,必须依靠其他线程调研 notify或者notifyAll方法才能被换下,wait是object类的方法
- 同步阻塞:运行的线程执行sleep或者join方法。或者发出了I/O请求时。JVM会把该线程置为阻塞状态。当sleep状态超时。join等待线程终止或者超时。线程重新转入就绪状态。sleep是Thread类的方法
生命周期的五种状态分别带出哪些操作
- 新建状态:新创建了一个线程对象
- 就绪状态:线程对象创建后,其他线程调用了该对象的start方法。该状态的线程位于可运行线程池中,变得可运行。等待获取CPU的使用权
- 运行状态:就绪状态的线程获取了CPU,执行程序代码
- 阻塞状态:阻塞状态是线程因为某种原因放弃CPU使用权。暂时停止运行。直到线程进入就绪状态,才有集合转到运行状态。
- 死亡状态:线程执行完了或者因异常退出了RUN方法,该线程结束生命周
Sleep和wait的区别
- sleep是Thread类的静态本地方法,wait则是Object类的本地方法。
- sleep方法不会释放lock,但是wait会释放,而且会加入到等待队列中【
sleep就是把cpu的执行资格和执行权释放出去,不在运行此线程,当定时时间结束再取回CPU资源,参与CPU的调度,获取到cpu资源后就可以继续运行了。而如果sleep时该线程有锁,那么sleep不会释放这个锁。而是把锁带着进入了冻结状态,也就是说其他需要这个锁线程根本不可能获取到这个锁。也就是说无法执行程序。如果在水面期间其他线程调用了这个线程的interrupt方法,那么这个线程也会抛出interruptexception异常返回,这点wait一样
- sleep方法不依赖于同步器synchronized,但是wait需要依赖synchronized关键字
- sleep不需要被唤醒(休眠之后推出阻塞),但是wait需要(不指定时间需要被别人中断)
- sleep一般用于当前线程休眠,或者轮询暂停操作,wait则多用于多线程之前的通信。
- sleep会让出cpu执行时间且强制上下文切换,而wait则不一定,wait后可能还是有机会重新竞争到锁继续执行的。
- yield ()执行后线程直接进入就绪状态,马上释放了cpu执行权,但是依然保留了cpu的执行资格,所以有可能cpu下次进入线程调度还会让这个线程获取执行权继续执行
- join()执行后线程进入阻塞状态,列如在线程B中调用线程A的join,那线程B会进入到阻塞队列,直到线程A结束或者中断线程。
3. 低代码框架选型
若依 | 芋道 | Jeecg | |
---|---|---|---|
公司内使用现状 | 芯月牧科使用 | 支付系统使用 | 风控项目组使用 |
团队熟悉度 | 团队成员对其较熟悉,因为该框架与Java语言紧密集成,对于熟悉Java的团队来说学习曲线较为平缓。 | 由于是较新的框架,团队成员对其相对不熟悉。需要投入额外的时间和资源来学习和掌握。 | 团队成员对其有一定了解,但需要进一步熟悉其架构和组件。可以通过培训和文档来提高团队技能。 |
BUG程度 | 经过长时间的发展和社区反馈,大部分BUG已经被修复。但仍需注意已知BUG,并持续关注官方发布和社区讨论。 | 在某些功能上存在已知的BUG,但官方团队积极修复,并且社区活跃度较高,容易获得帮助。 | 相对较为稳定,但也有一些已知的小BUG。官方团队和社区都会积极解决这些问题。 |
开源程度 | 完全开源,意味着任何人都可以查看和修改其源代码。这有助于形成一个活跃的社区,并促进框架的发展和改进。 | 部分开源(需要交199元),这意味着它的某些部分可能不公开或仅部分开源。这可能会限制社区的贡献和可定制性。 | 完全开源,并且由于其与Java的紧密集成,有大量的开源社区资源和支持。 |
封装程度 | 提供了丰富的组件和功能,易于集成到现有系统中。它也支持各种自定义配置和扩展。 | 相对轻量级的封装,更多依赖于开发者的能力进行定制和扩展。这需要一定的技能集,但对于经验丰富的开发人员来说可能更具灵活性。 | 提供了较多的封装和预置功能,这使得它易于使用,特别是对于初学者。但对于高级用户,可能封装较多的功能使其不够灵活。 |
定制化难度 | 提供了较多的定制选项,可以通过修改配置或扩展现有组件来满足特定需求。但需要一定的技术背景和对Java的了解。 | 具有较强的定制化能力,可以通过代码或配置进行深度定制。这为开发者提供了更大的灵活性来满足业务需求。 | 有一定的定制化能力,但相对有限。对于复杂的业务逻辑或特定需求,可能需要额外的开发工作。 |
生态成熟度 | 生态较为成熟,有较多的第三方插件和资源。 | 有一定的生态支持,但相对有限。 | 生态较为丰富,有较多的社区支持和资源。 |
技术优点 |
|
|
|
技术缺点 |
|
|
|
性能优点 | 性能表现稳定,能够满足大多数应用场景的需求。但在高负载或复杂场景下可能需要额外的优化措施。 | 性能表现稳定,能够满足大多数应用场景的需求。但在高负载或复杂场景下可能需要额外的优化措施。 | 性能表现良好,通常能够满足常见的Web应用性能需求。但对于极端负载或复杂业务逻辑,可能需要进一步的优化措施。 |
性能缺点 |
|
|
|
安全优点 | 提供了一些基本的安全措施和保护机制,如数据加密、身份验证等。但可能需要额外的安全配置和加固来满足更高级的安全需求 | 注重安全性,提供了多种安全特性,如数据加密、访问控制和权限管理等。这有助于确保应用的安全性和数据完整性。 | 安全性能较强,符合常见的安全标准和实践。但仍然需要开发者注意安全最佳实践并在开发过程中实施适当的安全措施。 |
安全缺点 |
|
|
|
目录结构 | 若依框架的目录结构也相对清晰,按照功能模块进行划分,每个模块都有自己的目录和文件。同时,若依框架还支持多模块开发,方便大型项目的构建和管理。 | 芋道框架的目录结构相对清晰,按照功能模块进行划分,每个模块都有自己的目录和文件。这种目录结构有助于代码的组织和管理,方便开发和维护 | Jeecg框架的目录结构相对固定,遵循一定的规范和约定。例如,控制器放在专门的Controller目录下,模型放在Model目录下等。这种目录结构有助于提高代码的可读性和可维护性 |
4. 租户隔离选型
DATASOURCE 模式(分库) | SCHEMA 模式(分表) | COLUMN 模式(字段隔离) | |
---|---|---|---|
优点 | (1)性能好,可以横向扩容。可以针对租户的性能需求,配置不同性能的数据库实例。例如,租户A的数据多,用户多,要求性能高,数据库实例的配置可以分配更多的内存、更高频率CPU;租户B的数据少,用户少,性能要求低,数据库实例的配置低一些没关系; (2)数据隔离性好; | (1)成本较低,支持的租户较多; ( 4 ) 为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可以支持更多的租户数量。 | (1)成本低,支持的租户多; 截器即可; ( 5 )维护和购置成本最低,允许每个数据库支持的租户数量最多。 |
缺点 | (1)系统升级不方便,需求所有数据库都执行一次表变更的sql。随着租户增加,运维的工作量会越来越多; (2)增加一个租户,需要创建一个新的数据库,增加运维的工作量; (3)增加一个租户时,要插入一些初始化数据,开发、运维之间,要维护一个初始化数据sql文件。生产中,经常会出现由于缺少部分初始化数据,导致新租户异常的情况; (4)运营做数据分析时,不方便; | 如果出现故障,数据恢复比较困难,因为恢复数据库将牵扯到其他租户的数据; 如果需要跨租户统计数据,存在一定困难 | (1)数据隔离性差; (2)所有数据存在一起,性能随着数据的增加会变得越来越差; |
资源共享度 | 资源共享度最低 | 资源共享度中等 | 资源共享度最高 |
实现难度 | 较复杂 需要为每个租户配置独立的数据库实例,涉及较多的资源管理和配置工作。 | 中等 需要在数据库层面实现表结构的动态创建和管理,相对较简单。 | 简单 需要在数据查询和存储时进行字段级别的控制,实现起来较为复杂。 |
性能 | 由于每个租户的数据存储在独立的数据库实例中,对数据库的并发访问可能会受到影响。 | 根据不同租户的数据访问模式进行表级别的优化可以提高性能。但表数量的增加可能会对数据库查询性能产生影响。 | 对特定字段的查询和操作可以优化数据库的查询性能,但可能增加数据处理和存储的复杂性。 |
计费统计 | 由于每个租户都有独立的数据存储,计费统计需要针对每个数据库实例进行,可能增加统计的复杂性和工作量。 | 每个租户的数据表可以独立统计,适用于按租户进行计费和统计的情况。 | 计费统计与具体实现方式有关,可能需要额外设计统计逻辑,以准确计算每个租户的使用情况。 |
隔离性 | 隔离性最高将不同租户的数据存储在不同的数据库实例中,可以实现数据的完全隔离。每个租户只能访问自己的数据库,保证了数据的安全性和隐私性。 | 隔离性中等通过为每个租户创建单独的数据表,可以实现表级别的隔离。不同租户的数据存储在不同的表中,可以控制租户之间的数据访问,但可能存在一些交叉操作的风险。 | 隔离性最低只将必要的数据字段提供给租户,保证了敏感数据的隔离。但需要仔细设计数据模型,并确保所有租户所需的数据字段都得到满足。 |