暂无个人介绍
前言 本文主要对数据库事务的一些基础概念进行总结,目的是为理解 Spring 的事务管理展开铺垫,并不涉及底层事务的实现,文中所提到的事务均为单机事务。
介绍 @EnableAspectJAutoProxy 注解是 Spring AOP 框架提供给用户开启 AspectJ 注解支持的一个开关。将其添加到 Spring 配置类上,然后就可以在 Spring Bean 上使用 AspectJ 注解,将 bean 配置为一个 Aspect。
前言 Spring AOP 主要具有三种使用方式,分别是注解、XML 配置、API,目前在 Spring 中,由于 XML 需要大量配置,注解已经逐步取代 XML 配置,而 API 需要对 Spring 底层具有较深入的了解才能使用,因此注解成了应用 Spring 的首选方式。
前言 Spring AOP 作为 Spring Framework 的核心模块,对 Spring IOC 加以补充,Spring 内部使用它提供了企业级的服务,如事务、异步、缓存等,同时它也允许用户自定义 Aspect,以便用 AOP 补充对 OOP 的使用。通常情况下,我们会通过 AspectJ 的注解来使用 Spring AOP,那么 Spring 一共提供了哪些使用 AOP 的方式呢?本篇将对其总结,并尝试了解 Spring AOP 的内部实现。
背景 为了支持数据库字段与复杂 Java 类型之间的转换,最近我所参与的项目中使用到了 MyBatis TypeHandler,由于 MyBatis 设计问题,如果为同一个泛型类的不同参数类型创建多个 TypeHandler,后面注册的 TypeHandler 会将前面注册的 TypeHandler 覆盖,从而引发错误,因此这里做一篇总结,并提供给其他小伙伴一些解决思路。
前言 软件开发的流程一般可分为分析、设计、实现,设计模式在处于设计或代码实现阶段,以设计思想、设计原则作为指导,相对来说更为具象,是前人对经常遇到的设计问题总结出的一套解决方案,多数设计模式用来解决代码的扩展性问题,在框架中使用的场景较多。
定义 模板方法是结构型设计模式的一种,它定义了算法的骨架,并将算法中的某些步骤推迟到子类实现。模板方法可以让子类重新定义算法中的某些步骤,而不需要修改算法的整体结构。
定义 责任链模式是结构型设计模式的一种,它将请求的发送者与接收者解耦,给多个对象处理请求的机会。请求沿着链传递,直到链上的接收对象可以处理该请求为止。
装饰器模式是结构性设计模式中的一种,结构型设计模式主要总结了一些将类或接口组合在一起的经典结构,装饰器模式用于对现有的类的功能进行增强。
建造者模式同样是创建型设计模式的一种,用于解决复杂对象的创建问题。
工厂模式 与单例模式一样,工厂模式同样属于创建型设计模式的一种。单例模式用于保证一个类只有一个实例,而工厂模式则用于创建类型相关的不同对象,它同样具有不同的实现方式,具体可以细分为简单工厂、工厂方法、抽象工厂,分别适用于不同的场景。
前言 经典的设计模式有23种,分为创建型、结构型、行为型,分别适用于不同的场景。由于设计模式过多,很难一篇文章就讲清楚,因此后面的文章会将常见的设计模式做一个拆分的介绍。
前言 缓存主要用来提高查询效率。以计算机的 CPU 为例,CPU 具有三级缓存,性能依次降低,优先从一级缓存查询,一级缓存未命中时再从二级缓存查询,二级缓存未命中时再从三级缓存查询。
前言 扩展性是衡量软件质量的重要标准,MyBatis 作为一款优秀的持久层框架自然也提供了扩展点,那就是我们今天谈到的插件。MyBaits 的插件拦截内部组件方法的执行,利用插件可以插入自定义的逻辑,例如常用的支持物理分页的 PageHelper 插件。
前言 MyBatis 执行 SQL 的核心接口为 SqlSession 接口,该接口提供了一些 CURD 及控制事务的方法,另外还可以通过 SqlSession 先获取 Mapper 接口的实例,然后通过 Mapper 接口执行 SQL,Mapper 接口方法的执行最终还是委托到 SqlSession 中的方法。
前言 通过前面入门 MyBatis 的文章《MyBatis 初探,使用 MyBatis 简化数据库操作(超详细)》,我们已经对 MyBatis 有了一定了解。
MyBatis 的源码相对于 Spring 来说更为简单,因此并没有花费太多的时间。本篇作为 MyBatis 的入门篇,
代理模式 设计模式最初由 GOF 在《设计模式》一书中总结,将其划分为创建型、结构型、行为型三大类。其中结构型模式总结了一些将类或对象组合在一起的经典结构。
语句 Statement 用于执行 SQL,返回执行结果 ResultSet,主要分为三种,分别是 Statement、PreparedStatement、CallableStatement,下面分别加以介绍。
前言 Spring 应用上下文(ApplicationContext),是 Spring 应用的核心接口,也是我们常说的 Spring 容器,除了扩展了基础容器 BeanFactory 还提供了更多企业级的特性,如资源管理、事件发布、国际化等。
前言 最近刚换了新工作,正在熟悉公司环境,因此博客更新有所耽误,那么本篇也是选自入职部门分享的主题,从今年5月份开始,我也在阅读 Spring 的源码,参考网络上的内容以及本人学习的一些经验,总结出本篇。
背景 为了友好的支持各个国家的语言,Java 本身已经提供了对国际化的支持,上篇文章《Java 国际化与文本格式化》已经介绍了 Java 对国际化的支持。
国际化标准实现 Java 中的字符使用 Unicode 编码,因此支持各个国家的语言。如果开发的软件仅在中国使用,那么我们直接使用中文即可。
什么是URL? URL 即 Uniform Resource Locator,翻译为中文为统一资源定位符,表示万维网上的一个资源,资源可以是实际存在的一个文件,也可以是抽象的数据库的查询结果。
前言 Spring 作为 IOC 容器,管理的对象称之为 bean,Java 对象在 ClassLoader 中有自己的创建和清理过程,那么 Spring Bean 在容器中也有自己的生命周期。
前言 Spring 支持注入单一类型和集合类型的依赖,对于单一类型,如果按照类型进行注入,容器中存在多个相同类型的 bean 时,Spring 将抛出 NoUniqueBeanDefinitionException 异常。对于这种情况,我们可以选择将某一个 bean 设置为 primary,然而如果存在多个 primary 的 bean,Spring 仍将无法处理,这时便引出我们今天介绍的 @Qualifier,使用 @Qualifier 可以明确指出注入哪个 bean。
背景 接上篇《Spring 依赖注入的方式,你了解哪些?》,上篇介绍了 Spring 包括 setter、字段、构造器、方法、接口回调等依赖注入的几种方式以及依赖注入的来源,更多的是停留在认识或者使用层面。这篇从源码的角度进行分析,Spring 在依赖注入的过程中如何解析依赖。
适配器模式定义 适配器模式是结构型设计模式的一种,通过使用继承或组合的方式将不兼容的接口适配为另一种兼容的接口。
前言 依赖查找和依赖注入是 Spring 实现 IoC 容器提供的两大特性,相对于依赖查找,Spring 更推崇的是使用依赖注入,本篇先对 Spring 中依赖注入的几种方式进行介绍,后续再分享其实现。
前言 Spring 事件处理基于 Java 观察者模式扩展。Spring 应用上下文中发布了各种事件,此外 Spring 还允许我们发送和处理自定义的事件,本篇将对 Spring 的事件机制使用及其实现进行详细介绍。
前言 泛型自 Java 5 诞生,为了支持泛型,Java 5 新增了 Type 类,表示 Java 中的某一种类型,反射包中提供的获取泛型类型的方法中多是返回 Type 类型,使用时需要进行强制类型转换,为了简化对泛型信息的获取,Spring 4 开始提供了一个 ResolvableType,本篇将详细对其分析。
前言 泛型是 Java 5 新增的一项特性,可以理解为类型的参数,主要用于代码重用,语义化代码,避免运行时的强制类型转换异常。
前言 依赖查找和依赖注入是 Spring IOC 容器提供的核心特性,Spring 建议尽量使用依赖注入的方式,另外 Spring 也提供了相关的 API 供用户进行依赖查找,Spring 依赖注入的能力同样依赖于依赖查找,这篇我们将关注 Spring 有哪些依赖查找的方法。
背景 做为一名 Java 程序员,日常开发中使用最多的便是 Spring,工作了很多年,很多人都停留在使用的层面上,甚至连最基本的概念都没搞懂。笔者在 Java 领域也辛勤耕耘了几年,为了避免浮于表面,在今年6月份开始看 Spring 的源码,其优秀的设计确实值得每一个 Java 开发者去学习。
xml 配置解析 xml 配置文件的解析由 XmlBeanDefinitionReader 来完成。XmlBeanDefinitionReader 加载 BeanDefinition 的入口方法如下。
什么是 BeanDefinition? BeanDefinition 直译为 bean 定义,描述了一个 bean 实例具有的构造方法参数和属性值等信息。与 Java 中的 Class 类似,Class 是类文件在内存中的表现形式,BeanDefinition 是 Spring Bean 配置元信息在内存中的表现形式,各种配置元信息最后都会被转换为 BeanDefinition ,Spring 根据 BeanDefinition 实例化、初始化 bean,BeanDefinition 涉及到 Spring Bean 的整个生命周期。
理解 Scope Scope 表示 Spring bean 的作用范围,指明了 bean 的生命周期。
如何理解 Environment? Environment 由 Spring 3.1 版本提出,表示当前应用的运行时环境。用于管理 Spring 中的条件配置 Profiles 和配置属性源。
如何理解 Environment? Environment 由 Spring 3.1 版本提出,表示当前应用的运行时环境。用于管理 Spring 中的条件配置 Profiles 和配置属性源。
概述 Spring 的项目中,我们经常会使用 @Enable 开头的注解到配置类中,添加了这种注解之后,便会开启一些功能特性。常用的注解如 @EnableWebMvc、@EnableTransactionManagement、@EnableAsync、@EnableScheduling 等等。
概述 @Conditional 是 Spring 4.0 提出的一个新的注解,可以用在类或方法上,当标注的对象满足所有的条件时,才能注册为 Spring 中的 bean。条件由使用 Spring 的用户自己指定,例如指定的 bean 不存在时注册、不同的环境注册不同的bean 等。
Spring 为什么引入资源管理? Java 中有各种各样的资源,资源的位置包括本地文件系统、网络、类路径等,资源的形式可以包括文件、二进制流、字节流等,针对不同的资源又有不同的加载形式。
前言 接上篇 Spring 5 启动性能优化之 @Indexed,上篇提到 Spring 可以在编译时生成索引文件,在应用上下文启动时可以通过索引文件查找所需要的注册的 Bean,如果不存在索引文件或者配置了不处理索引文件的参数,则不会从索引文件获取元数据。这时,Spring 便需要从指定的包中扫描 bean。
背景 Spring 经过近20年的发展,目前版本已经迭代到了5.x,每个版本 Spring 都有不同的改进,版本 5.x 中,Spring 把重心放到了性能优化上。我们知道,Spring 注解驱动编程中,Spring 启动时需要对类路径下的包进行扫描,以便发现所需管理的 bean。如果在应用启动前能够确定 Spring bean,不再进行扫描,那么性能就会大大提高,Spring 5 对此进行了实现。
前言 上篇 Spring 注解编程模型 有提到,Spring 对 Java 中的注解进行了增强,使用组合注解或者属性别名,可以让注解中的属性值覆盖元注解的属性值,并且不同的属性可以互为别名,这样在使用时只需要指定其中一个属性,其别名值也间接进行了提供。这篇便从源码进行入手,尝试分析其内部的实现。
前言 注解作为一种元数据,需要其他地方进行读取,在前面的文章 重识 Java 注解 中我们了解到,在运行时可以通过反射获取注解信息。元注解 @Retention 定义了注解的保留策略,具体有 SOURCE、CLASS、RUNTIME,那么保留策略不为运行时的注解有什么用呢?
什么是Java反射? Java 反射机制是 Java 自诞生以来就具备的能力,用于在 Java 程序运行过程中动态的获取类的信息,调用类中的方法。
前言 最近维护一个老项目,项目使用最原始的Servlet,项目中充斥着各种类似判空的简单校验,为了减少重复代码,因此需要手动引入 Java 的 Bean Validation。
前言 最近维护一个老项目,项目使用最原始的Servlet,项目中充斥着各种类似判空的简单校验,为了减少重复代码,因此需要手动引入 Java 的 Bean Validation。
前言 前面两篇文章 Spring基础容器BeanFactory 和 Spring FactoryBean 源码分析 已经详细的介绍了BeanFactory和FactoryBean,Spring中还存在一个ObjectFactory,它们之间不仅名称非常相似,事实上功能也有一些区别和联系。初学Spring的小伙伴可能很难区分它们之间有什么区别,这篇文章将简单对它们加以区分。