BAT面试题汇总及详解(进大厂必看)02 前面一般有用看3

Mysql（连老师）

数据库基础知识

为什么要使用数据库

数据保存在内存

数据保存在文件

数据保存在数据库

什么是SQL？

什么是MySQL?

数据库三大范式是什么

mysql有关权限的表都有哪几个

MySQL的binlog有有几种录入格式？分别有什么区别？

数据类型

mysql有哪些数据类型

引擎

MySQL存储引擎MyISAM与InnoDB区别

MyISAM索引与InnoDB索引的区别？

InnoDB引擎的4大特性

存储引擎选择

索引

什么是索引？

索引有哪些优缺点？

索引使用场景（重点）

索引有哪几种类型？

索引的数据结构（

b树，hash）

索引的基本原理

索引算法有哪些？

索引设计的原则？

创建索引的原则（重中之重）

创建索引时需要注意什么？

使用索引查询一定能提高查询的性能吗？为什么

百万级别或以上的数据如何删除

前缀索引

什么是最左前缀原则？什么是最左匹配原则

B树和B+树的区别

使用B树的好处

使用B+树的好处

Hash索引和B+树所有有什么区别或者说优劣呢?

数据库为什么使用B+树而不是B树

B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据

什么是聚簇索引？何时使用聚簇索引与非聚簇索引

非聚簇索引一定会回表查询吗？

联合索引是什么？为什么需要注意联合索引中的顺序？

事务

什么是数据库事务？

事物的四大特性(ACID)介绍一下?

什么是脏读？幻读？不可重复读？

什么是事务的隔离级别？MySQL的默认隔离级别是什么？

锁

对MySQL的锁了解吗

隔离级别与锁的关系

按照锁的粒度分数据库锁有哪些？锁机制与InnoDB锁算法

从锁的类别上分MySQL都有哪些锁呢？

像上面那样子进行锁定岂不是有点阻碍并发效率了

MySQL中InnoDB引擎的行锁是怎么实现的？

InnoDB存储引擎的锁的算法有三种什么是死锁？怎么解决？

数据库的乐观锁和悲观锁是什么？怎么实现的？

视图

为什么要使用视图？什么是视图？

视图有哪些特点？

视图的使用场景有哪些？

视图的优点

视图的缺点

什么是游标？

存储过程与函数

什么是存储过程？有哪些优缺点？

触发器

什么是触发器？触发器的使用场景有哪些？

MySQL中都有哪些触发器？

常用SQL语句

SQL语句主要分为哪几类

超键、候选键、主键、外键分别是什么？

SQL约束有哪几种？

六种关联查询

什么是子查询

子查询的三种情况

mysql中in和exists区别

varchar与char的区别

varchar(50)中50的涵义

int(20)中20的涵义

mysql为什么这么设计

mysql中int(10)和char(10)以及varchar(10)的区别

FLOAT和DOUBLE的区别是什么？

drop、delete与truncate的区别

三者都表示删除，但是三者有一些差别：

UNION与UNIONALL的区别？

SQL优化

如何定位及优化SQL语句的性能问题？

创建的索引有没有被使用到?或者说怎么才可以知道这条语句运行很慢的原因？

SQL的生命周期？

大表数据查询，怎么优化

超大分页怎么处理？

mysql分页

慢查询日志

关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过？

慢查询都怎么优化过？

为什么要尽量设定一个主键？

主键使用自增ID还是UUID？

字段为什么要求定义为not null？

如果要存储用户的密码散列，应该使用什么字段进行存储？

优化查询过程中的数据访问

优化长难的查询语句

优化特定类型的查询语句

优化关联查询

优化子查询

优化LIMIT分页

优化UNION查询

优化WHERE子句

数据库优化

为什么要优化

数据库结构优化

MySQL数据库cpu飙升到500%的话他怎么处理？

大表怎么优化？某个表有近千万数据，CRUD比较慢，如何优化？分库分表了是怎么

做的？分表分库了有什么问题？有用到中间

件么？他们的原理知道么？

垂直分表

适用场景

缺点

水平分表：

适用场景

MySQL的复制原理以及流程

读写分离有哪些解决方案？

备份计划，mysqldump以及xtranbackup的实现原理

数据表损坏的修复方式有哪些？

MySQL记录binlog的方式主要包括三种模式？每种模式的优缺点是什么？

MySQL锁，悲观锁、乐观锁、排它锁、共享锁、表级锁、行级锁；

MySQL InnoDB中，乐观锁、悲观锁、共享锁、排它锁、行锁、表锁、死锁概念的理解

乐观锁

悲观锁

共享锁

排它锁

行锁

表锁

死锁

分布式事务的原理2阶段提交，同步异步阻塞非阻塞；

数据库事务隔离级别，MySQL默认的隔离级别

Spring如何实现事务

spring事务管理(详解和实例)

1 初步理解

2 核心接口

2.1 事务管理器

2.2 基本事务属性的定义

2.3 事务状态

3 编程式事务

3.1 编程式和声明式事务的区别

3.2 如何实现编程式事务？

4 声明式事务

4.1 配置方式

4.2 一个声明式事务的实例

Spring事务管理及几种简单的实现

JDBC如何实现事务

嵌套事务实现

Spring事务管理--(二)嵌套事物详解

一、前言

二、spring嵌套事物

1、展示项目代码--简单测springboot项目

2、外部起事物，内部起事物，内外都无Try Catch

3、外部起事物，内部起事物，外部有Try Catch

4、外部起事物，内部起事物，内部有Try Catch

5、外部起事物，内部起事物，内外有Try Catch

三、嵌套事物总结

四、正确的嵌套事物实例

分布式事务实现；

分布式事务与解决方案

前言

产生原因

数据库分库分表：

应用SOA化：

应用场景

支付、转账：在线下单：

电商场景：流量充值业务

数据库事务

事务类型：

隔离级别及引发现象：（略谈）

Spring事务传播行为：（略谈）

事务种类：

如何保证强一致性

本地事务（mysql 之 InnoDB）：

分布式事务：

实现分布式事务解决方案

基于XA协议的两阶段提交（

2PC）

补偿事务（

TCC）

本地消息表（MQ 异步确保）

MQ 事务消息

Sagas 事务模型

其他补偿方式

总结

SQL的整个解析、执行过程原理、SQL行转列；

mysql行转列、列转行

行转列

列转行

红黑树的实现原理和应用场景；

MySql的存储引擎的不同

MySQL存储引擎之Myisam和Innodb总结性梳理

Mysql优化系列--Innodb引擎下mysql自身配置优化

Mysql怎么分表，以及分表后如果想按条件分页查询怎么办(如果不是按分表字段来查询的话，几乎效率低下，

无解)

mysql 数据库分表后怎么进行分页查询？Mysql分库分表方案?

mysql大数据量使用limit分页，随着页码的增大，查询效率越低下。

测试实验

1. 直接用limit start, count分页语句，也是我程序中用的方法：

2. 对limit分页问题的性能优化方法

MySQL分表自增ID解决方案

理解分布式id生成算法SnowFlake

概述

Talk is cheap, show you the code

代码理解

负数的二进制表示

用位运算计算n个bit能表示的最大数值

用mask防止溢出

用位运算汇总结果

观察

扩展

MySql的主从实时备份同步的配置，以及原理(从库读主库的binlog)，读写分离

Mysql主从同步的实现原理

MySQL索引背后的数据结构及算法原理

摘要

数据结构及算法基础

索引的本质

B-Tree和B+Tree

B-Tree

B+Tree

带有顺序访问指针的B+Tree

为什么使用B-Tree（B+Tree）

主存存取原理

磁盘存取原理

局部性原理与磁盘预读B-/+Tree索引的性能分析

MySQL索引实现

MyISAM索引实现

InnoDB索引实现

索引使用策略及优化

示例数据库

最左前缀原理与相关优化

情况一：全列匹配。

情况二：最左前缀匹配。

情况三：查询条件用到了索引中列的精确匹配，但是中间某个条件未提供。

情况四：查询条件没有指定索引第一列。

情况五：匹配某列的前缀字符串。

情况六：范围查询。

情况七：查询条件中含有函数或表达式。

索引选择性与前缀索引

InnoDB的主键选择与插入优化

后记

mysql的锁--行锁，表锁，乐观锁，悲观锁

Mysql中的MVCC

1. Innodb的事务相关概念

2. 行的更新过程

1. 初始数据行

2.事务1更改该行的各字段的值

3.事务2修改该行的值

4. 事务提交

5. Insert Undo log

3. 事务级别

4. MVCC

5.总结

mysql索引原理之聚簇索引

学习笔记_mysql索引原理之B+/-Tree

关系型和非关系型数据库区别

我的Mysql死锁排查过程（案例分析）

死锁起因

分析

阅读死锁日志

死锁形成流程图

拓展

总结

MySql优化

MySQL 对于千万级的大表要怎么优化？

产生死锁的必要条件

操作系统：死锁的产生、条件、和解锁

产生死锁的原因主要是：

产生死锁的四个必要条件：

死锁的解除与预防

死锁排除的方法

Spring（连老师）

Spring 原理

Spring 特点

Spring 核心组件

Spring 常用模块

Spring 主要包

Spring 常用注解

Spring 第三方结合

Spring IOC 原理

Spring APO 原理

Spring MVC 原理Spring AOP的实现原理和场景；

一、场景

二、实现技术

Spring bean的作用域和生命周期；

作用域

生命周期

Spring 5比Spring4做了哪些改进；

Spring 4.x新特性

Spring 5.x新特性

Spring4新特性——泛型限定式依赖注入

Spring4新特性——核心容器的其他改进

Spring4新特性——Web开发的增强

Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC

1、集成Bean Validation 1.1到SpringMVC

2、分组验证及分组顺序

3、消息中使用EL表达式

4、方法参数/返回值验证

5、自定义验证规则

6、类级别验证器

7、通过脚本验证

8、cross-parameter，跨参数验证

9、混合类级别验证器和跨参数验证器

10、组合验证注解

11、本地化

Spring4新特性——Groovy Bean定义DSL

一、对比

二、Groovy Bean定义

三、Groovy Bean定义 DSL语法

Spring4新特性——更好的Java泛型操作API

Spring4新特性——JSR310日期时间API的支持

Spring4新特性——注解、脚本、任务、MVC等其他特性改进

一、注解方面的改进

二、脚本的支持

三、Future增强

四、MvcUriComponentsBuilder

五、Socket支持

如何自定义一个Spring Boot Starter？

本章内容概览

版本信息

官方资料

设定实战目标

学习spring cloud的starter

如何建立对spring-cloud-netflix-eureka-client模块的依赖

为什么应用能自动注册到Eureka sever

实战的设计

自定义spring boot starter三部曲之二：实战开发

本章内容概述

创建工程customizestarter

创建模块customizeapi

创建模块addservice

创建模块minusservice

创建模块customizeservicestarter

构建工程customizestarter

创建工程customizestartertestdemo

构建工程customizestartertestdemo

验证支持负数的减法服务

验证不支持负数的减法服务

自定义spring boot starter三部曲之三：源码分析spring.factories加载过程版本情况

初步分析

spring容器如何处理配置类

spring boot配置类的加载情况

Spring IOC是什么？优点是什么？

Spring IOC原理解读面试必读

一、什么是Ioc/DI？

二、 Spring IOC体系结构？

三、IoC容器的初始化？

四、IOC容器的依赖注入

五、IoC容器的高级特性

SpringMVC

动态代理

反射

AOP原理

Spring事务；

springMVC的原理

Spring MVC工作原理及注解说明

SpringMVC框架介绍

SpringMVC原理图

SpringMVC接口解释

SpringMVC运行原理

spring中beanFactory和ApplicationContext的联系和区别

Spring系列之beanFactory与ApplicationContext

spring注入的几种方式（循环注入）

Spring循环依赖的三种方式

第一种：构造器参数循环依赖

第二种：setter方式单例，默认方式

第三种：setter方式原型，prototype

springIOC

Spring IOC原理解读面试必读

一、什么是Ioc/DI？

二、 Spring IOC体系结构？

三、IoC容器的初始化？

四、IOC容器的依赖注入

五、IoC容器的高级特性

spring AOP的原理

Spring AOP 实现原理与 CGLIB 应用

AOP 的存在价值

图 1.多个地方包含相同代码的软件

图 2 通过方法调用实现系统功能

使用 AspectJ 的编译时增强进行 AOP

清单 1.Hello.java

清单 2.TxAspect.java

清单 3.LogAspect.java

清单 4.Hello.class

使用 Spring AOP

清单 5.Chinese.java

清单 6.AfterReturningAdviceTest.java

清单 7.AfterReturningAdviceTest.java

清单 8.bean.xml

清单 9.BeanTest.java

清单 10.Person.java

清单 11.BeanTest.java

Spring AOP 原理剖析

图 3.AOP 代理的方法与目标对象的方法

使用 CGLIB 生成代理类

清单 12.AroundAdvice.java清单 13.ChineseProxyFactory.java

清单 14.Main.java

结束语

spring AOP 两种代理方式

Spring 如何保证 Controller 并发的安全？

springMVC一个Controller处理所有用户请求的并发问题

Spring并发访问的线程安全性问题

spring中用到哪些设计模式？

Spring IOC 的理解，其初始化过程？

Spring的事务管理

1 初步理解

2 核心接口

2.1 事务管理器

2.1.1 JDBC事务

2.1.2 Hibernate事务

2.1.3 Java持久化API事务（

JPA）

2.1.4 Java原生API事务

2.2 基本事务属性的定义

2.2.1 传播行为

2.2.2 隔离级别

2.2.3 只读

2.2.4 事务超时

2.2.5 回滚规则

2.3 事务状态

3 编程式事务

3.1 编程式和声明式事务的区别

3.2 如何实现编程式事务？

3.2.1 使用TransactionTemplate

3.2.2 使用PlatformTransactionManager

4 声明式事务

4.1 配置方式

4.2 一个声明式事务的实例

SpringMVC概述

什么是Spring MVC？简单介绍下你对Spring MVC的理解？

Spring MVC的优点

Spring MVC的主要组件？

什么是DispatcherServlet

什么是Spring MVC框架的控制器？

Spring MVC的控制器是不是单例模式,如果是,有什么问题,怎么解决？

工作原理

请描述Spring MVC的工作流程？描述一下 DispatcherServlet 的工作流程？

MVC框架

MVC是什么？MVC设计模式的好处有哪些

常用注解

注解原理是什么

Spring MVC常用的注解有哪些？

SpingMvc中的控制器的注解一般用哪个,有没有别的注解可以替代？

@Controller注解的作用

@RequestMapping注解的作用

@ResponseBody注解的作用

@PathVariable和@RequestParam的区别

其他

Spring MVC与Struts2区别

Spring MVC怎么样设定重定向和转发的？

Spring MVC怎么和AJAX相互调用的？

如何解决POST请求中文乱码问题，GET的又如何处理呢？

Spring MVC的异常处理？

如果在拦截请求中，我想拦截get方式提交的方法,怎么配置怎样在方法里面得到Request,或者Session？

如果想在拦截的方法里面得到从前台传入的参数,怎么得到？

如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象？

Spring MVC中函数的返回值是什么？

Spring MVC用什么对象从后台向前台传递数据的？

怎么样把ModelMap里面的数据放入Session里面？

Spring MVC里面拦截器是怎么写的

介绍一下 WebApplicationContext

Spring概述

1. 什么是spring?

2. Spring框架的设计目标，设计理念，和核心是什么

3. Spring的优缺点是什么？

4. Spring有哪些应用场景

5. Spring由哪些模块组成？

6. Spring 框架中都用到了哪些设计模式？

7. 详细讲解一下核心容器（

spring context应用上下文) 模块

8. Spring框架中有哪些不同类型的事件

9. Spring 应用程序有哪些不同组件？

10. 使用 Spring 有哪些方式？

Spring控制反转(IOC)

什么是Spring IOC 容器？

控制反转(IoC)有什么作用

IOC的优点是什么？

Spring IoC 的实现机制

Spring 的 IoC支持哪些功能

BeanFactory 和 ApplicationContext有什么区别？

Spring 如何设计容器的，BeanFactory和 ApplicationContext的关系详解

ApplicationContext通常的实现是什么？

什么是Spring的依赖注入？

依赖注入的基本原则

依赖注入有什么优势

有哪些不同类型的依赖注入实现方式？

构造器依赖注入和 Setter方法注入的区别

Spring Beans（

19）什么是Spring beans？

一个 Spring Bean 定义包含什么？

如何创建一个如何给Spring 容器提供配置元数据？Spring有几种配置方式

Spring配置文件包含了哪些信息

Spring基于xml注入bean的几种方式

你怎样定义类的作用域？

解释Spring支持的几种bean的作用域

Spring框架中的单例bean是线程安全的吗？

Spring如何处理线程并发问题？

哪些是重要的bean生命周期方法？你能重载它们吗？

什么是Spring的内部bean？什么是Spring inner beans？

在 Spring中如何注入一个java集合？

什么是bean装配？

什么是bean的自动装配？

解释不同方式的自动装配，spring 自动装配 bean 有哪些方式？

使用@Autowired注解自动装配的过程是怎样的？

自动装配有哪些局限性？

你可以在Spring中注入一个null 和一个空字符串吗？

Spring注解

什么是基于Java的Spring注解配置? 给一些注解的例子

怎样开启注解装配？

@Component, @Controller, @Repository, @Service 有何区别？

@Required 注解有什么作用

@Autowired 注解有什么作用

@Autowired和@Resource之间的区别@Qualifier 注解有什么作用

@RequestMapping 注解有什么用？

Spring数据访问

解释对象/关系映射集成模块

在Spring框架中如何更有效地使用JDBC？

解释JDBC抽象和DAO模块

spring DAO 有什么用？

spring JDBC API 中存在哪些类？

JdbcTemplate是什么

使用Spring通过什么方式访问Hibernate？使用 Spring 访问 Hibernate 的方法有哪些？

如何通扩展 Hib过HibernateDaoSupport将Spring和Hibernate 结合起来？

Spring支持的事务管理类型， spring 事务实现方式有哪些？

Spring事务的实现方式和实现原理

说一下Spring的事务传播行为

说一下 spring 的事务隔离？

Spring框架的事务管理有哪些优点？

你更倾向用那种事务管理类型？

Spring面向切面编程(AOP)什么是AOP

Spring AOP and AspectJ AOP 有什么区别？AOP 有哪些实现方式？

JDK动态代理和CGLIB动态代理的区别

InvocationHandler 的 invoke(Object proxy,Method method,Object[] args)：

如何理解 Spring 中的代理？

解释一下Spring AOP里面的几个名词

Spring在运行时通知对象

连接点的支持，而且它不支持构造器连接点。方法之外的连接点拦截功能，我们在Spring AOP 中，关注点

和横切关注的区别是什么？在 spring aop 中 concern 和 cross-cutting concern 的不同之处

Spring通知有哪些类型？

什么是切面 Aspect？

解释基于XML Schema方式的切面实现

有几种不同类型的自动代理？

SpringMVC面试题

什么是 SpringMvc？

Spring MVC 的优点：答：

SpringMVC 工作原理？答：

SpringMVC 流程？答：

SpringMvc 的控制器是不是单例模式,如果是,有什么问题,怎么解决？

如果你也用过 struts2.简单介绍下 springMVC 和 struts2 的区别有哪些?

SpingMvc 中的控制器的注解一般用那个,有没有别的注解可以替代？

@RequestMapping 注解用在类上面有什么作用？

怎么样把某个请求映射到特定的方法上面？

如果在拦截请求中,我想拦截 get 方式提交的方法,怎么配置？

怎么样在方法里面得到 Request,或者 Session？

我想在拦截的方法里面得到从前台传入的参数,怎么得到？

如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象？

SpringMvc 中函数的返回值是什么？

SpringMVC 怎么样设定重定向和转发的？

SpringMvc 用什么对象从后台向前台传递数据的？

SpringMvc 中有个类把视图和数据都合并的一起的,叫什么？

怎么样把 ModelMap 里面的数据放入 Session 里面？

SpringMvc 怎么和 AJAX 相互调用的？答：

讲下 SpringMvc 的执行流程

Spring Boot（连老师）

Spring Boot概述

什么是 Spring Boot？

Spring Boot 有哪些优点？

Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

配置

什么是 JavaConfig？Spring Boot 自动配置原理是什么？

你如何理解 Spring Boot 配置加载顺序？

4）命令行参数；什么是 YAML？

YAML 配置的优势在哪里 ?

Spring Boot 是否可以使用 XML 配置 ?

什么是 Spring Profiles？

如何在自定义端口上运行 Spring Boot 应用程序？

安全

如何实现 Spring Boot 应用程序的安全性？

比较一下 Spring Security 和 Shiro 各自的优缺点 ?

Spring Boot 中如何解决跨域问题 ?

什么是 CSRF 攻击？

监视器

Spring Boot 中的监视器是什么？

我们如何监视所有 Spring Boot 微服务？

整合第三方项目

什么是 WebSockets？

什么是 Spring Batch？

什么是 FreeMarker 模板？

如何集成 Spring Boot 和 ActiveMQ？

什么是 Apache Kafka？

什么是 Swagger？你用 Spring Boot 实现了它吗？

其他

如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？Spring Boot项目如何热部署？

您使用了哪些 starter maven 依赖项？

运行 Spring Boot 有哪几种方式？

Spring Boot 需要独立的容器运行吗？

开启 Spring Boot 特性有哪几种方式？

如何使用 Spring Boot 实现异常处理？

如何使用 Spring Boot 实现分页和排序？

Spring Boot 中如何实现定时任务 ?

Spring Boot 原理

Spring Boot比Spring做了哪些改进？

Spring boot 热加载

Spring Boot设置有效时间和自动刷新缓存，时间支持在配置文件中配置

Spring Boot缓存实战 Redis 设置有效时间和自动刷新缓存，时间支持在配置文件中配置

问题描述

解决思路

CacheManager说明

Cache说明

请求步骤

代码分析

hibernate和ibatis的区别

Ibatis与Hibernate的区别

一、 hibernate与ibatis之间的比较：

二、hibernate与ibatis两者的对比：

三、iBatis与Hibernate区别？

四、选择Hibernate还是iBATIS都有它的道理：

讲讲mybatis的连接池。

Mybatis数据源与连接池

一、MyBatis数据源DataSource分类

二、数据源DataSource的创建过程

三、 DataSource什么时候创建Connection对象

四、不使用连接池的UnpooledDataSource

五、为什么要使用连接池？

六、使用了连接池的PooledDataSource

七、JNDI类型的数据源DataSource

经典面试题问题一

问题二

问题三

问题四

问题五

问题六

问题七

问题八

问题九

问题十

问题十一

问题十二

问题十三

问题十四

问题十五

问题十六

问题十七

问题十八

问题十九

问题二十

问题二十一

问题二十二

Spring Cloud（一明老师，晁老师）

Spring Cloud熔断机制介绍；

Spring Cloud对比下Dubbo，什么场景下该使用Spring Cloud？

CAP原理和BASE理论

CAP原则(CAP定理)、BASE理论

一、CAP原则

一致性与可用性的决择编辑

取舍策略

BASE理论

基本可用

最终一致性

小结：

与NoSQL的关系编辑

CAP的是什么关系

为什么会是这样

选择权衡

延伸

分布式系统的典型应用

分布式事务、分布式锁

常用的分布式事务解决方案介绍有多少种？

一、一致性理论

二、一致性模型

三、分布式事务解决方案

四、选择建议

分布式锁的几种实现方式

1. 使用Redis实现分布式锁

* WATCH, MULTI, EXEC, DISCARD事务机制实现分布式锁

* SETNX实现分布式锁

* 锁的释放

2. 使用Memcached实现分布式锁

3. 使用ZooKeeper实现分布式锁

获取锁

释放锁

获取锁

释放锁

Spring Cloud面试题什么是 Spring Cloud？

使用 Spring Cloud 有什么优势？

服务注册和发现是什么意思？Spring Cloud 如何实现？

负载平衡的意义什么？

什么是 Hystrix？它如何实现容错？

什么是Hystrix 断路器？我们需要它吗？

什么是 Netflix Feign？它的优点是什么？

什么是 Spring Cloud Bus？我们需要它吗？

为什么需要学习Spring Cloud

什么是Spring Cloud

设计目标与优缺点

优缺点

Spring Cloud发展前景

整体架构

主要项目

Spring Cloud Config

Spring Cloud Netflix

Spring Cloud Bus

Spring Cloud Sleuth

Spring Cloud Stream

Spring Cloud Task

Spring Cloud OpenFeign

Spring Cloud的版本关系

Spring Cloud和SpringBoot版本对应关系

Spring Cloud和各子项目版本对应关系

SpringBoot和SpringCloud的区别？

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

服务注册和发现是什么意思？Spring Cloud 如何实现？

负载平衡的意义什么？

什么是 Hystrix？它如何实现容错？

什么是 Hystrix 断路器？我们需要它吗？

什么是 Netflix Feign？它的优点是什么？

什么是 Spring Cloud Bus？我们需要它吗？

Spring Cloud断路器的作用

什么是Spring Cloud Config?

什么是Spring Cloud Gateway?

开始-----------------

一. 分布式模型

1. 节点

异常

副本

3. 衡量分布式系统的指标

Mysql（连老师）

数据库基础知识为什么要使用数据库

数据保存在内存

优点：存取速度快

缺点：数据不能永久保存

数据保存在文件

优点：数据永久保存

缺点：1）速度比内存操作慢，频繁的IO操作。

数据保存在数据库

1）数据永久保存

2）使用SQL语句，查询方便效率高。

3）管理数据方便

什么是SQL？

结构化查询语言(StructuredQueryLanguage)简称SQL，是一种数据库查询语言。

作用：用于存取数据、查询、更新和管理关系数据库系统。

什么是MySQL?

MySQL是一个关系型数据库管理系统，由瑞典MySQLAB公司开发，属于Oracle旗下产品。MySQL是最

流行的关系型数据库管理系统之一，在WEB应用方面，MySQL是最好的

RDBMS(RelationalDatabaseManagementSystem，关系数据库管理系统)应用软件之一。在Java企业级

开发中非常常用，因为MySQL是开源免费的，并且方便扩展。

数据库三大范式是什么

第一范式：每个列都不可以再拆分。

第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。

第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。

在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我

们经常会为了性能而妥协数据库的设计。

mysql有关权限的表都有哪几个

MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由

mysql_install_db脚本初始化。这些权限表分别user，db，table_priv，columns_priv和host。下面分

别介绍一下这些表的结构和内容：

user权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。

db权限表：记录各个帐号在各个数据库上的操作权限。

table_priv权限表：记录数据表级的操作权限。

2）查询数据不方便columns_priv权限表：记录数据列级的操作权限。

host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和

REVOKE语句的影响。

MySQL的binlog有有几种录入格式？分别有什么区别？

有三种格式，statement，row和mixed。

statement模式下，每一条会修改数据的sql都会记录在binlog中。不需要记录每一行的变化，减少

了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因此在保存的时候需要保存

相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。

row级别下，不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，

基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如altertable)，因此这种模式的

文件保存的信息太多，日志量太大。

mixed，一种折中的方案，普通操作使用statement记录，当无法使用statement的时候使用row。

此外，新版的MySQL中对row级别也做了一些优化，当表结构发生变化的时候，会记录语句而不是逐行

记录。

数据类型

mysql有哪些数据类型分类

类型名称

说明

整数类型

tinyInt

很小的整数(8位

二进制)

smallint

小的整数(16位二进制)

mediumint

中等大小的整数(24位二进制)

int(integer)

普通大小的整数(32位二进制)

小数类型

float

单精度浮点数

double

双精度浮点数

decimal(m,d)

压缩严格的定点数

日期类型

year

YYYY1901~2155

time

HH:MM:SS-838:59:59~838:59:59

date

YYYYMM-DD1000-01-01~9999-12-3

datetime

YYYYMM-DDHH:MM:SS1000-01-0100:00:00~9999-12-

3123:59:59

timestamp

YYYYMM-DDHH:MM:SS1970010100:00:01UTC~2038-

01-1903:14:07UTC

文本、二进制

类型

CHAR(M)

M为0~65535之

间的整数

VARCHAR(M)

M为0~65535之间的整数

TINYBLOB

允许长度0~255字节

BLOB

允许长度0~65535字节

MEDIUMBLOB

允许长度0~167772150字节

LONGBLOB

允许长度0~4294967295字节

TINYTEXT

允许长度0~255字节

TEXT

允许长度0~65535字节

MEDIUMTEXT

允许长度0~167772150字节

LONGTEXT

允许长度0~4294967295字节

VARBINARY(M)

允许长度0~M个字节的变长字节字符串

BINARY(M)

允许长度0~M个字节的定长字节字符串

整数类型，包括TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，分别表示1字节、2字节、3字

节、4字节、8字节整数。任何整数类型都可以加上UNSIGNED属性，表示数据是无符号的，即非负整

数。长度：整数类型可以被指定长度，例如：INT(11)表示长度为11的INT类型。长度在大多数场景是没有意

义的，它不会限制值的合法范围，只会影响显示字符的个数，而且需要和UNSIGNEDZEROFILL属性配合

使用才有意义。

例子，假定类型设定为INT(5)，属性为UNSIGNEDZEROFILL，如果用户插入的数据为12的话，那么数据

库实际存储数据为00012。

实数类型，包括FLOAT、DOUBLE、DECIMAL。DECIMAL可以用于存储比BIGINT还大的整型，能存储

精确的小数。而FLOAT和DOUBLE是有取值范围的，并支持使用标准的浮点进行近似计算。

计算时FLOAT和DOUBLE相比DECIMAL效率更高一些，DECIMAL你可以理解成是用字符串进行处理。

字符串类型，包括VARCHAR、CHAR、TEXT、BLOBVARCHAR用于存储可变长字符串，它比定长类型更

节省空间。

VARCHAR使用额外1或2个字节存储字符串长度。列长度小于255字节时，使用1字节表示，否则使用2字

节表示。

VARCHAR存储的内容超出设置的长度时，内容会被截断。

CHAR是定长的，根据定义的字符串长度分配足够的空间。

CHAR会根据需要使用空格进行填充方便比较。

CHAR适合存储很短的字符串，或者所有值都接近同一个长度。

CHAR存储的内容超出设置的长度时，内容同样会被截断。

使用策略：

对于经常变更的数据来说，CHAR比VARCHAR更好，因为CHAR不容易产生碎片。

对于非常短的列，CHAR比VARCHAR在存储空间上更有效率。

使用时要注意只分配需要的空间，更长的列排序时会消耗更多内存。尽量避免使用TEXT/BLOB类型，查

询时会使用临时表，导致严重的性能开销。

枚举类型（ENUM），把不重复的数据存储为一个预定义的集合。有时可以使用ENUM代替常用的字符

串类型。ENUM存储非常紧凑，会把列表值压缩到一个或两个字节。ENUM在内部存储时，其实存的是

整数。尽量避免使用数字作为ENUM枚举的常量，因为容易混乱。排序是按照内部存储的整数

日期和时间类型，尽量使用timestamp，空间效率高于datetime，用整数保存时间戳通常不方便处理。

如果需要存储微妙，可以使用bigint存储。

看到这里，这道真题是不是就比较容易回答了。

引擎

MySQL存储引擎MyISAM与InnoDB区别

存储引擎Storageengine：MySQL中的数据、索引以及其他对象是如何存储的，是一套文件系统的实

现。

常用的存储引擎有以下：

Innodb引擎：Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的

设计的目标就是处理大数据容量的数据库系统。

MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。

MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。

MyISAM与InnoDB区别MyISAM

Innodb

存储结构

每张表被存放在三个文件：frm-

表格定义、MYD(MYData)-数据

文件、MYI(MYIndex)-索引文件

所有的表都保存在同一个数据文件中

（也可能是多个文件，或者是独立的表

空间文件），InnoDB表的大小只受限

于操作系统文件的大小，一般为2GB

存储空间

MyISAM可被压缩，存储空间较

小

InnoDB的表需要更多的内存和存储，

它会在主内存中建立其专用的缓冲池用

于高速缓冲数据和索引

可移植性、备份

及恢复

由于MyISAM的数据是以文件的

形式存储，所以在跨平台的数据

转移中会很方便。在备份和恢复

时可单独针对某个表进行操作

免费的方案可以是拷贝数据文件、备份

binlog，或者用mysqldump，在数据

量达到几十G的时候就相对痛苦了

文件格式

数据和索引是分别存储的，数

据.MYD，索引.MYI

数据和索引是集中存储的，.ibd

记录存储顺序

按记录插入顺序保存

按主键大小有序插入

外键

不支持

支持

事务

不支持

支持

锁支持（锁是避

免资源争用的一

个机制，MySQL

锁对用户几乎是

透明的）

表级锁定

行级锁定、表级锁定，锁定力度小并发

能力高

SELECT

MyISAM更优

INSERT、

UPDATE、

DELETE

InnoDB更优

selectcount(*)

myisam更快，因为myisam内

部维护了一个计数器，可以直接

调取。

索引的实现方式

B+树索引，myisam是堆表

B+树索引，Innodb是索引组织表

哈希索引

不支持

支持

全文索引

支持

不支持

MyISAM索引与InnoDB索引的区别？

InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。

InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。

MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。

InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会

非常高效。InnoDB引擎的4大特性

插入缓冲（insertbuffer)

二次写(doublewrite)

自适应哈希索引(ahi)

预读(readahead)

存储引擎选择

如果没有特别的需求，使用默认的Innodb即可。

MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。

Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，

支持事务和外键。比如OA自动化办公系统。

索引

什么是索引？

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它

们包含着对数据表里所有记录的引用指针。

索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新

数据库表中数据。索引的实现通常使用B树及其变种

B+树。

更通俗的说，索引就相当于目录。为了方便查找书中的内容，通过对内容建立索引形成目录。索引是一

个文件，它是要占据物理空间的。

索引有哪些优缺点？

索引使用场景（重点）

上图中，根据id查询记录，因为id字段仅建立了主键索引，因此此SQL执行可选

的索引只有主键索引，如果有多个，最终会选一个较优的作为检索的依据。

1--增加一个没有建立索引的字段

2altertableinnodb1addsexchar(1);

3--按sex检索时可选的索引为null

4EXPLAINSELECT*frominnodb1wheresex='男';可以尝试在一个字段未建立索引时，根据该字段查询的效率，然后对该字段建立索引

（altertable表名addindex(字段名)），同样的SQL执行的效率，你会发现查询效率

会有明显的提升（数据量越大越明显）。

orderby

当我们使用orderby将查询结果按照某个字段排序时，如果该字段没有建立索

引，那么执行计划会将查询出的所有数据使用外部排序（将数据从硬盘分批读取到内存使用内部排序，

最后合并排序结果），这个操作是很影响性能的，因为需要将查询涉及到的所有数据从磁盘中读到内存

（如果单条数据过大或者数据量过多都会降低效率），更无论读到内存之后的排序了。

但是如果我们对该字段建立索引altertable表名addindex(字段名)，那么由于索引本身是有序的，因此直

接按照索引的顺序和映射关系逐条取出数据即可。而且如果分页的，那么只用取出索引表某个范围内的

索引对应的数据，而不用像上述那取出所有数据进行排序再返回某个范围内的数据。（从磁盘取数据是

最影响性能的）

join

对join语句匹配关系（on）涉及的字段建立索引能够提高效率

索引覆盖

如果要查询的字段都建立过索引，那么引擎会直接在索引表中查询而不会访问原始数据（否则只要有一

个字段没有建立索引就会做全表扫描），这叫索引覆盖。

因此我们需要尽可能的在select后只写必要的查询字段，以增加索引覆盖的几

率。

这里值得注意的是不要想着为每个字段建立索引，因为优先使用索引的优势就在于其体积小。

索引有哪几种类型？

主键索引:数据列不允许重复，不允许为NULL，

一个表只能有一个主键。

唯一索引:数据列不允许重复，允许为NULL值，

一个表允许多个列创建唯一索引。

可以通过ALTERTABLEtable_nameADDUNIQUE(column);

创建唯一索引

可以通过ALTERTABLEtable_nameADDUNIQUE(column1,column2);

创建唯一组合索引

普通索引:基本的索引类型，没有唯一性的限制，允许为NULL值。

可以通过ALTERTABLEtable_nameADDINDEXindex_name(column);

创建普通索引

可以通过ALTERTABLEtable_nameADDINDEXindex_name(column1,column2,column3);

创建组合索引

全文索引：是目前搜索引擎使用的一种关键技术。

可以通过ALTERTABLEtable_nameADDFULLTEXT(column);

创建全文索引

索引的数据结构（b树，hash）

索引的数据结构和具体存储引擎的实现有关，在MySQL中使用较多的索引有

Hash索引，B+树索引等，而我们经常使用的InnoDB存储引擎的默认索引实现为：B+树索引。对于哈希

索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索

引，查询性能快；其余大部分场景，建议选择BTree索引。

1）B树索引mysql通过存储引擎取数据，基本上90%的人用的就是InnoDB了，按照实现方式分，

InnoDB的索引类型目前只有两种：BTREE（B树）索引和HASH索引。B树索引是Mysql数据库中使用频

繁的索引类型，基本所有存储引擎都支持BTree索引。通常我们说的索引不出意外指的就是（B树）索引（实际是用B+树实现的，因为在查看表索

引时，mysql一律打印BTREE，所以简称为B树索引）

查询方式：

主键索引区:PI(关联保存的时数据的地址)按主键查询,

普通索引区:si(关联的id的地址,然后再到达上面的地址)。所以按主键查询,速度快

B+tree性质：

1.）n棵子tree的节点包含n个关键字，不用来保存数据而是保存数据的索引。

2.）所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依

关键字的大小自小而大顺序链接。

3.）所有的非终端结点可以看成是索引部分，结点中仅含其子树中的大（或小）关键字。

4.）B+树中，数据对象的插入和删除仅在叶节点上进行。

5.）B+树有2个头指针，一个是树的根节点，一个是小关键码的叶节点。2）哈希索引简要说下，类似于

数据结构中简单实现的HASH表（散列表）一样，当我们在

mysql中用哈希索引时，主要就是通过Hash算法（常见的Hash算法有直接定址法、平方取中法、折叠

法、除数取余法、随机数法），将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入

Hash表的对应位置；如果发生

Hash碰撞（两个不同关键字的Hash值相同），则在对应Hash键下以链表形式存储。当然这只是简略模

拟图。索引的基本原理

索引用来快速地寻找那些具有特定值的记录。如果没有索引，一般来说执行查询时遍历整张表。

索引的原理很简单，就是把无序的数据变成有序的查询

1. 把创建了索引的列的内容进行排序

2. 对排序结果生成倒排表

3. 在倒排表内容上拼上数据地址链

4. 在查询的时候，先拿到倒排表内容，再取出数据地址链，从而拿到具体数据

索引算法有哪些？

索引算法有BTree算法和Hash算法

BTree算法

BTree是常用的mysql数据库索引算法，也是mysql默认的算法。因为它不仅可以被用在=,>,>=,<,<=和

between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的

常量，例如：

Hash算法

HashHash索引只能用于对等比较，例如=,<=>（相当于=）操作符。由于是一次定位数据，不像BTree索

引需要从根节点到枝节点，后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。

索引设计的原则？

1.适合索引的列是出现在where子句中的列，或者连接子句中指定的列

2.基数较小的类，索引效果较差，没有必要在此列建立索引

3.使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间

4.不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行

更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。

创建索引的原则（重中之重）

索引虽好，但也不是无限制的使用，好符合一下几个原则

1）左前缀匹配原则，组合索引非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、

between、like)就停止匹配，比如a=1andb=2andc>3andd=4如果建立(a,b,c,d)顺序的索引，d是用不到

索引的，如果建立

(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

2）较频繁作为查询条件的字段才去创建索引

3）更新频繁字段不适合创建索引

4）若是不能有效区分数据的列不适合做索引列(如性别，男女未知，多也就三种，区分度实在太低)

5）尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改

原来的索引即可。

1 --只要它的查询条件是一个不以通配符开头的常量

2 select*fromuserwherenamelike'jack%';

3 --如果一通配符开头，或者没有使用常量，则不会使用索引，例如：

4 select*fromuserwherenamelike'%jack';6）定义有外键的数据列一定要建立索引。

7）对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。8）对于定义为text、image和bit

的数据类型的列不要建立索引。创建索引的三种方式，删除索引

第一种方式：在执行CREATETABLE时创建索引

1 CREATETABLEuser_index2(

2 idINTauto_incrementPRIMARYKEY,

3 first_nameVARCHAR(16),

4 last_nameVARCHAR(16),

5 id_cardVARCHAR(18),

6 informationtext,

7 KEYname(first_name,last_name),

8 FULLTEXTKEY(information),

9 UNIQUEKEY(id_card));

第二种方式：使用ALTERTABLE命令去增加索引

1ALTERTABLEtable_nameADDINDEXindex_name(column_list);

ALTERTABLE用来创建普通索引、UNIQUE索引或PRIMARYKEY索引。

其中table_name是要增加索引的表名，column_list指出对哪些列进行索引，多列时各列之间用逗号分

隔。

索引名index_name可自己命名，缺省时，MySQL将根据第一个索引列赋一个名称。另外，

ALTERTABLE允许在单个语句中更改多个表，因此可以在同时创建多个索引。

第三种方式：使用CREATEINDEX命令创建

1CREATEINDEXindex_nameONtable_name(column_list);

CREATEINDEX可对表增加普通索引或UNIQUE索引。（但是，不能创建PRIMARYKEY索引）

删除索引

根据索引名删除普通索引、唯一索引、全文索引：altertable表名dropKEY索引名

1 altertableuser_indexdropKEYname;

2 altertableuser_indexdropKEYid_card;

3 altertableuser_indexdropKEYinformation;

删除主键索引：altertable表名dropprimarykey（因为主键只有一个）。这里值得注意的是，如果主键

自增长，那么不能直接执行此操作（自增长依赖于主键索引）：

需要取消自增长再行删除：但通常不会删除主键，因为设计主键一定与业务逻辑无关。

创建索引时需要注意什么？

非空字段：应该指定列为NOTNULL，除非你想存储NULL。在mysql中，含有空值的列很难进行查

询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值

或者一个空串代替空值；

取值离散大的字段：（变量各个取值之间的差异程度）的列放到联合索引的前面，可以通过count()

函数查看字段的差异值，返回值越大说明字段的唯一值越多字段的离散程度高；

索引字段越小越好：数据库的数据存储以页为单位一页存储的数据越多一次IO操作获取的数据越大

效率越高。

使用索引查询一定能提高查询的性能吗？为什么

通常，通过索引查询数据比全表扫描要快。但是我们也必须注意到它的代价。

索引需要空间来存储，也需要定期维护，每当有记录在表中增减或索引列被修改时，索引本身也会被修

改。这意味着每条记录的INSERT，DELETE，UPDATE将为此多付出4，5次的磁盘I/O。因为索引需要额

外的存储空间和处理，那些不必要的索引反而会使查询反应时间变慢。使用索引查询不一定能提高查询

性能，索引范围查询(INDEXRANGESCAN)适用于两种情况:

基于一个范围的检索，一般查询返回结果集小于表中记录数的30%

基于非唯一性索引的检索

百万级别或以上的数据如何删除

关于索引：由于索引需要额外的维护成本，因为索引文件是单独存在的文件,所以当我们对数据的增加,修

改,删除,都会产生额外的对索引文件的操作,这些操作需要消耗额外的IO,会降低增/改/删的执行效率。所

以，在我们删除数据库百万级别数据的时候，查询MySQL官方手册得知删除数据的速度和创建的索引数

量是成正比的。

1. 所以我们想要删除百万数据的时候可以先删除索引（此时大概耗时三分多钟）

2. 然后删除其中无用数据（此过程需要不到两分钟）

3. 删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分

钟左右。

4. 与之前的直接删除绝对是要快速很多，更别说万一删除中断,一切删除会回滚。那更是坑了。

前缀索引

语法：index(field(10))，使用字段值的前10个字符建立索引，默认是使用字段的全部内容建立索引。

前提：前缀的标识度高。比如密码就适合建立前缀索引，因为密码几乎各不相

同。

实操的难度：在于前缀截取的长度。

我们可以利用selectcount(*)/count(distinctleft(password,prefixLen));，通过从调整prefixLen的值（从

1自增）查看不同前缀长度的一个平均匹配度，接近1时就可以了（表示一个密码的前prefixLen个字符几

乎能确定唯一一条记录）

1 altertableuser_index

2 --重新定义字段

3 MODIFYidint,

4 dropPRIMARYKEY什么是最左前缀原则？什么是最左匹配原则

顾名思义，就是最左优先，在创建多列索引时，要根据业务需求，where子句中

使用最频繁的一列放在最左边。

最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)

就停止匹配，比如a=1andb=2andc>3andd=4如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建

立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

=和in可以乱序，比如a=1andb=2andc=3建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化

成索引可以识别的形式

B树和B+树的区别

在B树中，你可以将键和值存放在内部节点和叶子节点；但在B+树

中，内部节点都是键，没有值，叶子节点同时存放键和值。

B+树的叶子节点有一条链相连，而B树的叶子节点各自独立。

使用B树的好处

B树可以在内部节点同时存储键和值，因此，把频繁访问的数据放在靠近根节点的地方将会大大提高热

点数据的查询效率。这种特性使得B树在特定数据重复多次查询的场景中更加高效。

使用B+树的好处

由于B+树的内部节点只存放键，不存放值，因此，一次读取，可以在内存页中获取更多的键，有利于更

快地缩小查找范围。B+树的叶节点由一条链相连，因此，当需要进行一次全数据遍历的时候，B+树只需

要使用O(logN)时间找到最小的一个节点，然后通过链进行O(N)的顺序遍历即可。而B树则需要对树的每

一层进行遍历，这会需要更多的内存置换次数，因此也就需要花费更多的时间

Hash索引和B+树所有有什么区别或者说优劣呢?

首先要知道Hash索引和B+树索引的底层实现原理：

hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应

的键值，之后进行回表查询获得实际数据。B+树底层实现是多路平衡查找树。

对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然

后根据查询判断是否需要回表查询数据。

么可以看出他们有以下的不同：hash索引进行等值查询更快(一般情况下)，但是却无法进行范围查询。

因为在hash索引中经过hash函数建立索引之后，索引的顺序与原顺序无法保持一致，不能支持范围查

询。而B+树的的所有节点皆遵循(左节点小于父节点，右节点大于父节点，多叉树也类似)，天然支持范

围。

hash索引不支持使用索引进行排序，原理同上。

hash索引不支持模糊查询以及多列索引的最左前缀匹配。原理也是因为hash函

数的不可预测。AAAA和AAAAB的索引没有相关性。

hash索引任何时候都避免不了回表查询数据，而B+树在符合某些条件(聚簇索

引，覆盖索引等)的时候可以只通过索引完成查询。

hash索引虽然在等值查询上较快，但是不稳定。性能不可预测，当某个键值存在大量重复的时候，发生

hash碰撞，此时效率可能极差。而B+树的查询效率比较稳定，对于所有的查询都是从根节点到叶子节

点，且树的高度较低。

因此，在大多数情况下，直接选择B+树索引可以获得稳定且较好的查询速度。

而不需要使用hash索引。

数据库为什么使用B+树而不是B树

B树只适合随机检索，而B+树同时支持随机检索和顺序检索；

B+树空间利用率更高，可减少I/O次数，磁盘读写代价更低。一般来说，索引本

身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引

查找过程中就要产生磁盘I/O消耗。B+树的内部结点并没有指向关键字具体信息的指针，只是作为索引

使用，其内部结点比B树小，盘块能容纳的结

点中关键字数量更多，一次性读入内存中可以查找的关键字也就越多，相对的，IO读

写次数也就降低了。而IO读写次数是影响索引检索效率的最大因素；

B+树的查询效率更加稳定。B树搜索有可能会在非叶子结点结束，越靠近根节点的记录查找时间越短，

只要找到关键字即可确定记录的存在，其性能等价于在关键字全集内做一次二分查找。而在B+树中，顺

序检索比较明显，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的

查找路径长度相同，导致每一个关键字的查询效率相当。

B-树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。B+树的叶子节点使用指针顺序

连接在一起，只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁

的，而B树不支持这样的操作。

增删文件（节点）时，效率更高。因为B+树的叶子节点包含所有关键字，并以

有序的链表结构存储，这样可很好提高增删效率。

B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据

在B+树的索引中，叶子节点可能存储了当前的key值，也可能存储了当前的key值以及整行的数据，这就

是聚簇索引和非聚簇索引。在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则挑选一个唯一键

建立聚簇索引。如果没有唯一键，则隐式的生成一个键来建立聚簇索引。

当查询使用聚簇索引时，在对应的叶子节点，可以获取到整行数据，因此不用再

次进行回表查询。什么是聚簇索引？何时使用聚簇索引与非聚簇索引

聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据

非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过

key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索

引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因

澄清一个概念：innodb中，在聚簇索引之上创建的索引称之为辅助索引，辅助索引访问数据总是需要二

次查找，非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引，辅助索引叶子节点存储的不再

是行的物理位置，而是主键值

何时使用聚簇索引与非聚簇索引

非聚簇索引一定会回表查询吗？

不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了

索引，那么就不必再进行回表查询

举个简单的例子，假设我们在员工表的年龄上建立了索引，那么当进行select age from employee

where age < 20的查询时，在索引的叶子节点上，已经包含了age信息，不会再次进行回表查询。

联合索引是什么？为什么需要注意联合索引中的顺序？

MySQL可以使用多个字段同时建立一个索引，叫做联合索引。在联合索引中，如果想要命中索引，需要

按照建立索引时的字段顺序挨个使用，否则无法命中索引。

具体原因为:

MySQL使用索引时需要索引有序，假设现在建立了"name，age，school"的联合索引，那么索引的排序

为: 先按照name排序，如果name相同，则按照age排序，如果age的值也相等，则按照school进行排

序。

当进行查询时，此时索引仅仅按照name严格有序，因此必须首先使用name字段进行等值查询，之后对

于匹配到的列而言，其按照age字段严格有序，此时可以使用age字段用做索引查找，以此类推。因此在

建立联合索引的时候应该注意索引列的顺序，一般情况下，将查询需求频繁或者字段选择性高的列放在

前面。此外可以根据特例的查询或者表结构进行单独的调整。

事务什么是数据库事务？

事务是一个不可分割的数据库操作序列，也是数据库并发控制的基本单位，其执行的结果必须使数据库

从一种一致性状态变到另一种一致性状态。事务是逻辑上的一组操作，要么都执行，要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。

假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小

红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小

红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。

事物的四大特性(ACID)介绍一下?

关系性数据库需要遵循ACID规则，具体内容如下：

原子性：事务是最小的执行单位，不允许分割。事务的原子性确保动作

要么全部完成，要么完全不起作用；

2. 一致性：执行事务前后，数据保持一致，多个事务对同一个数据读取的

结果是相同的；

3. 隔离性：并发访问数据库时，一个用户的事务不被其他事务所干扰，各

并发事务之间数据库是独立的；

4. 持久性：一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该

对其有任何影响。

什么是脏读？幻读？不可重复读？

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前

一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这

可能是两次查询过程中间插入了一个事务更新的原有的数据。隔离级别

脏读

不可重复读

幻影读

READ- UNCOM MITTED

√

READ- COMMIT TED

√

REPEATA BLE- READ

√

SERIALIZ ABLE

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数

据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据

是它先前所没有的。

什么是事务的隔离级别？MySQL的默认隔离级别是什么？

为了达到事务的四大特性，数据库定义了4种不同的事务隔离级别，由低到高依次为Read

uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、

不可重复读、幻读这几类问题。

SQL 标准定义了四个隔离级别：

READ-UNCOMMITTED(读取未提交)：最低的隔离级别，允许读取尚未提交的数据变更，可能会导

致脏读、幻读或不可重复读。

READ-COMMITTED(读取已提交)：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读

或不可重复读仍有可能发生。

REPEATABLE-READ(可重复读)：对同一字段的多次读取结果都是一致的，除非数据是被本身事务

自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

SERIALIZABLE(可串行化)：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执

行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻

读。

这里需要注意的是：Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle默认采用的

READ_COMMITTED隔离级别

事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC（多版本并发控制），通过

保存修改的旧版本信息来支持并发一致性读和回滚等特性。

因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读

取提交内容):，但是你要知道的是InnoDB 存储引擎默认使用 REPEATABLE-READ（可重读）并不会有

任何性能损失。

InnoDB 存储引擎在分布式事务的情况下一般会用到SERIALIZABLE(可串行化)隔离级别。

锁

对MySQL的锁了解吗

当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来

保证访问的次序，锁机制就是这样的一个机制。

就像酒店的房间，如果大家随意进出，就会出现多人抢夺同一个房间的情况，而在房间上装上锁，申请

到钥匙的人才可以入住并且将房间锁起来，其他人只有等他使用完毕才可以再次使用。隔离级别与锁的关系

在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修

改的数据上的排他锁冲突

在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；

在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须

等待事务执行完毕以后才释放共享锁。

SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完

成。

按照锁的粒度分数据库锁有哪些？锁机制与InnoDB锁算法

在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和

页级锁(BDB引擎 )。

MyISAM和InnoDB存储引擎使用的锁：

MyISAM采用表级锁(table-level locking)。

InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁

行级锁，表级锁和页级锁对比

行级锁行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减

少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁和排他锁。

特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，

并发度也最高。

表级锁表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消

耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表

共享读锁（共享锁）与表独占写锁（排他锁）。

特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，

并发度最低。

页级锁页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级

冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。

特点：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和

行锁之间，并发度一般

从锁的类别上分MySQL都有哪些锁呢？

像上面那样子进行锁定岂不是有点阻碍并发效率了

从锁的类别上来讲，有共享锁和排他锁。

共享锁: 又叫做读锁。当用户要进行数据的读取时，对数据加上共享锁。共享锁可以同时加上多个。

排他锁: 又叫做写锁。当用户要进行数据的写入时，对数据加上排他锁。排他锁只可以加一个，他和其

他的排他锁，共享锁都相斥。

用上面的例子来说就是用户的行为有两种，一种是来看房，多个用户一起看房是可以接受的。一种是真

正的入住一晚，在这期间，无论是想入住的还是想看房的都不可以。锁的粒度取决于具体的存储引擎，InnoDB实现了行级锁，页级锁，表级锁。

他们的加锁开销从大到小，并发能力也是从大到小。

MySQL中InnoDB引擎的行锁是怎么实现的？

答：InnoDB是基于索引来完成行锁

例: select * from tab_with_index where id = 1 for update;

for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id不是索引键那么InnoDB将

完成表锁，并发将无从谈起

InnoDB存储引擎的锁的算法有三种

Record lock：单个行记录上的锁

Gap lock：间隙锁，锁定一个范围，不包括记录本身

Next-key lock：record+gap 锁定一个范围，包含记录本身

相关授权文件。

一些文档、AspectJ 入门书籍，一谈到使用 AspectJ，就认为必须使用 Eclipse 工具，似乎离开了该工具

就无法使用 AspectJ 了。

虽然 AspectJ 是 Eclipse 基金组织的开源项目，而且提供了 Eclipse 的 AJDT 插件（AspectJ

Development Tools）来开发 AspectJ 应用，但 AspectJ 绝对无须依赖于 Eclipse 工具。

实际上，AspectJ 的用法非常简单，就像我们使用 JDK 编译、运行 Java 程序一样。下面通过一个简单的

程序来示范 AspectJ 的用法，并分析 AspectJ 如何在编译时进行增强。

首先编写一个简单的 Java 类，这个 Java 类用于模拟一个业务组件。

清单 1.Hello.java

显示更多

上面 Hello 类模拟了一个业务逻辑组件，编译、运行该 Java 程序，这个结果是没有任何悬念的，程序将

在控制台打印”Hello AspectJ”字符串。

假设现在客户需要在执行 sayHello() 方法之前启动事务，当该方法执行结束时关闭事务，在传统编程模

式下，我们必须手动修改 sayHello() 方法——如果改为使用 AspectJ，则可以无须修改上面的 sayHello()

方法。

下面我们定义一个特殊的 Java 类。

public class Hello

{

// 定义一个简单方法，模拟应用中的业务逻辑方法

public void sayHello(){System.out.println("Hello AspectJ!");}

// 主方法，程序的入口

public static void main(String[] args)

{

Hello h = new Hello();

h.sayHello();

}

}清单 2.TxAspect.java

显示更多

可能读者已经发现了，上面类文件中不是使用 class、interface、enum 在定义 Java 类，而是使用了

aspect ——难道 Java 语言又新增了关键字？没有！上面的 TxAspect 根本不是一个 Java 类，所以

aspect 也不是 Java 支持的关键字，它只是 AspectJ 才能识别的关键字。

上面粗体字代码也不是方法，它只是指定当程序执行 Hello 对象的 sayHello() 方法时，系统将改为执行

粗体字代码的花括号代码块，其中 proceed() 代表回调原来的 sayHello() 方法。

正如前面提到的，Java 无法识别 TxAspect.java 文件的内容，所以我们要使用 ajc.exe 命令来编译上面

的 Java 程序。为了能在命令行使用 ajc.exe 命令，需要把 AspectJ 安装目录下的 bin 路径（比如

E:\Java\AOP\aspectj1.6\bin 目录）添加到系统的 PATH 环境变量中。接下来执行如下命令进行编译：

ajc -d . Hello.java TxAspect.java

我们可以把 ajc.exe 理解成 javac.exe 命令，都用于编译 Java 程序，区别是 ajc.exe 命令可识别 AspectJ

的语法；从这个意义上看，我们可以将 ajc.exe 当成一个增强版的 javac.exe 命令。

运行该 Hello 类依然无须任何改变，因为 Hello 类位于 lee 包下。程序使用如下命令运行 Hello 类：

java lee.Hello

运行该程序，将看到一个令人惊喜的结果：

开始事务 …

Hello AspectJ!

事务结束 …

从上面运行结果来看，我们完全可以不对 Hello.java 类进行任何修改，同时又可以满足客户的需求：上

面程序只是在控制台打印”开始事务 …”、”结束事务 …”来模拟了事务操作，实际上我们可用实际的事务操

作代码来代替这两行简单的语句，这就可以满足客户需求了。

如果客户再次提出新需求，需要在 sayHello() 方法后增加记录日志的功能，那也很简单，我们再定义一

个 LogAspect，程序如下：

清单 3.LogAspect.java

public aspect TxAspect

{

// 指定执行 Hello.sayHello() 方法时执行下面代码块

void around():call(void Hello.sayHello()){System.out.println("开始事务

...");proceed();System.out.println("事务结束 ...");}

}

public aspect LogAspect

{

// 定义一个 PointCut，其名为 logPointcut

// 该 PointCut 对应于指定 Hello 对象的 sayHello 方法

pointcut logPointcut()

:execution(void Hello.sayHello());

// 在 logPointcut 之后执行下面代码块

after():logPointcut()

{

System.out.println("记录日志 ...");

}

}显示更多

上面程序的粗体字代码定义了一个 Pointcut：logPointcut – 等同于执行 Hello 对象的 sayHello() 方法，

并指定在 logPointcut 之后执行简单的代码块，也就是说，在 sayHello() 方法之后执行指定代码块。使

用如下命令来编译上面的 Java 程序：

ajc -d . *.java

再次运行 Hello 类，将看到如下运行结果：

开始事务 …

Hello AspectJ!

记录日志 …

事务结束 …

从上面运行结果来看，通过使用 AspectJ 提供的 AOP 支持，我们可以为 sayHello() 方法不断增加新功

能。

为什么在对 Hello 类没有任何修改的前提下，而 Hello 类能不断地、动态增加新功能呢？这看上去并不

符合 Java 基本语法规则啊。实际上我们可以使用 Java 的反编译工具来反编译前面程序生成的

Hello.class 文件，发现 Hello.class 文件的代码如下：

清单 4.Hello.class

显示更多

package lee;

import java.io.PrintStream;

import org.aspectj.runtime.internal.AroundClosure;

public class Hello

{

public void sayHello()

{

try

{

System.out.println("Hello AspectJ!"); } catch (Throwable localThrowable) {

LogAspect.aspectOf().ajc$after$lee_LogAspect$1$9fd5dd97(); throw

localThrowable; }

LogAspect.aspectOf().ajc$after$lee_LogAspect$1$9fd5dd97();

}

...

private static final void sayHello_aroundBody1$advice(Hello target,

TxAspect ajc$aspectInstance, AroundClosure ajc$aroundClosure)

{

System.out.println("开始事务 ...");

AroundClosure localAroundClosure = ajc$aroundClosure;

sayHello_aroundBody0(target);

System.out.println("事务结束 ...");

}

}不难发现这个 Hello.class 文件不是由原来的 Hello.java 文件编译得到的，该 Hello.class 里新增了很多

内容——这表明 AspectJ 在编译时”自动”编译得到了一个新类，这个新类增强了原有的 Hello.java 类的

功能，因此 AspectJ 通常被称为编译时增强的 AOP 框架。

提示：与 AspectJ 相对的还有另外一种 AOP 框架，它们不需要在编译时对目标类进行增强，而是运行时

生成目标类的代理类，该代理类要么与目标类实现相同的接口，要么是目标类的子类——总之，代理类

的实例可作为目标类的实例来使用。一般来说，编译时增强的 AOP 框架在性能上更有优势——因为运行

时动态增强的 AOP 框架需要每次运行时都进行动态增强。

实际上，AspectJ 允许同时为多个方法添加新功能，只要我们定义 Pointcut 时指定匹配更多的方法即

可。如下片段：

显示更多

上面程序中的 xxxPointcut 将可以匹配所有以 H 开头的类中、所有以 say 开头的方法，但该方法返回的

必须是 void；如果不想匹配任意的返回值类型，则可将代码改为如下形式：

pointcut xxxPointcut()

:execution( H.say*());

关于如何定义 AspectJ 中的 Aspect、Pointcut 等，读者可以参考 AspectJ 安装路径下的 doc 目录里的

quick5.pdf 文件。

使用 Spring AOP

与 AspectJ 相同的是，Spring AOP 同样需要对目标类进行增强，也就是生成新的 AOP 代理类；与

AspectJ 不同的是，Spring AOP 无需使用任何特殊命令对 Java 源代码进行编译，它采用运行时动态地、

在内存中临时生成”代理类”的方式来生成 AOP 代理。

Spring 允许使用 AspectJ Annotation 用于定义方面（Aspect）、切入点（Pointcut）和增强处理

（Advice），Spring 框架则可识别并根据这些 Annotation 来生成 AOP 代理。Spring 只是使用了和

AspectJ 5 一样的注解，但并没有使用 AspectJ 的编译器或者织入器（

Weaver ），底层依然使用的是

Spring AOP，依然是在运行时动态生成 AOP 代理，并不依赖于 AspectJ 的编译器或者织入器。

简单地说，Spring 依然采用运行时生成动态代理的方式来增强目标对象，所以它不需要增加额外的编

译，也不需要 AspectJ 的织入器支持；而 AspectJ 在采用编译时增强，所以 AspectJ 需要使用自己的编

译器来编译 Java 文件，还需要织入器。

为了启用 Spring 对 @AspectJ 方面配置的支持，并保证 Spring 容器中的目标 Bean 被一个或多个方面

自动增强，必须在 Spring 配置文件中配置如下片段：

pointcut xxxPointcut()

:execution(void H*.say*());

<?xml version="1.0" encoding="GBK"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

<aop:aspectj-autoproxy/>

</beans>显示更多

当然，如果我们希望完全启动 Spring 的”零配置”功能，则还需要启用 Spring 的”零配置”支持，让

Spring 自动搜索指定路径下 Bean 类。

所谓自动增强，指的是 Spring 会判断一个或多个方面是否需要对指定 Bean 进行增强，并据此自动生成

相应的代理，从而使得增强处理在合适的时候被调用。

如果不打算使用 Spring 的 XML Schema 配置方式，则应该在 Spring 配置文件中增加如下片段来启用

@AspectJ 支持。

显示更多

上面配置文件中的 AnnotationAwareAspectJAutoProxyCreator 是一个 Bean 后处理器

（BeanPostProcessor），该 Bean 后处理器将会为容器中 Bean 生成 AOP 代理，

当启动了 @AspectJ 支持后，只要我们在 Spring 容器中配置一个带 @Aspect 注释的 Bean，Spring 将

会自动识别该 Bean，并将该 Bean 作为方面 Bean 处理。

在 Spring 容器中配置方面 Bean（即带 @Aspect 注释的 Bean），与配置普通 Bean 没有任何区别，一

样使用元素进行配置，一样支持使用依赖注入来配置属性值；如果我们启动了 Spring 的”零配置”特性，

一样可以让 Spring 自动搜索，并装载指定路径下的方面 Bean。

使用 @Aspect 标注一个 Java 类，该 Java 类将会作为方面 Bean，如下面代码片段所示：

显示更多

方面类（用 @Aspect 修饰的类）和其他类一样可以有方法、属性定义，还可能包括切入点、增强处理定

义。

当我们使用 @Aspect 来修饰一个 Java 类之后，Spring 将不会把该 Bean 当成组件 Bean 处理，因此负

责自动增强的后处理 Bean 将会略过该 Bean，不会对该 Bean 进行任何增强处理。

开发时无须担心使用 @Aspect 定义的方面类被增强处理，当 Spring 容器检测到某个 Bean 类使用了

@Aspect 标注之后，Spring 容器不会对该 Bean 类进行增强。

下面将会考虑采用 Spring AOP 来改写前面介绍的例子：

下面例子使用一个简单的 Chinese 类来模拟业务逻辑组件：

清单 5.Chinese.java

<bean class="org.springframework.aop.aspectj.annotation.

AnnotationAwareAspectJAutoProxyCreator"/>

// 使用 @Aspect 定义一个方面类

@Aspect

public class LogAspect

{

// 定义该类的其他内容

...

}

@Component

public class Chinese

{

// 实现 Person 接口的 sayHello() 方法

public String sayHello(String name)显示更多

提供了上面 Chinese 类之后，接下来假设同样需要为上面 Chinese 类的每个方法增加事务控制、日志记

录，此时可以考虑使用 Around、AfterReturning 两种增强处理。

先看 AfterReturning 增强处理代码。

清单 6.AfterReturningAdviceTest.java

显示更多

上面 Aspect 类使用了 @Aspect 修饰，这样 Spring 会将它当成一个方面 Bean 进行处理。其中程序中粗

体字代码指定将会在调用 org.crazyit.app.service.impl 包下的所有类的所有方法之后织入 log(Object

rvt) 方法。

再看 Around 增强处理代码：

清单 7.AfterReturningAdviceTest.java

{

System.out.println("-- 正在执行 sayHello 方法 --");

// 返回简单的字符串

return name + " Hello , Spring AOP";

}

// 定义一个 eat() 方法

public void eat(String food)

{

System.out.println("我正在吃 :"+ food);

}

// 定义一个方面

@Aspect

public class AfterReturningAdviceTest

{

// 匹配 org.crazyit.app.service.impl 包下所有类的、

// 所有方法的执行作为切入点

@AfterReturning(returning="rvt",

pointcut="execution(* org.crazyit.app.service.impl.*.*(..))")

public void log(Object rvt)

{

System.out.println("获取目标方法返回值 :" + rvt);

System.out.println("模拟记录日志功能 ...");

}

// 定义一个方面

@Aspect

public class AroundAdviceTest

{

// 匹配 org.crazyit.app.service.impl 包下所有类的、

// 所有方法的执行作为切入点

@Around("execution(* org.crazyit.app.service.impl.*.*(..))")

public Object processTx(ProceedingJoinPoint jp)

throws java.lang.Throwable

{

System.out.println("执行目标方法之前，模拟开始事务 ...");

// 执行目标方法，并保存目标方法执行后的返回值显示更多

与前面的 AfterReturning 增强处理类似的，此处同样使用了 @Aspect 来修饰前面 Bean，其中粗体字代

码指定在调用 org.crazyit.app.service.impl 包下的所有类的所有方法的”前后（Around）” 织入

processTx(ProceedingJoinPoint jp) 方法

需要指出的是，虽然此处只介绍了 Spring AOP 的 AfterReturning、Around 两种增强处理，但实际上

Spring 还支持 Before、After、AfterThrowing 等增强处理，关于 Spring AOP 编程更多、更细致的编

程细节，可以参考《轻量级 Java EE 企业应用实战》一书。

本示例采用了 Spring 的零配置来开启 Spring AOP，因此上面 Chinese 类使用了 @Component 修饰，

而方面 Bean 则使用了 @Aspect 修饰，方面 Bean 中的 Advice 则分别使用了 @AfterReturning、

@Around 修饰。接下来只要为 Spring 提供如下配置文件即可：

清单 8.bean.xml

显示更多

接下来按传统方式来获取 Spring 容器中 chinese Bean、并调用该 Bean 的两个方法，程序代码如下：

清单 9.BeanTest.java

Object rvt = jp.proceed(new String[]{"被改变的参数"});

System.out.println("执行目标方法之后，模拟结束事务 ...");

return rvt + " 新增的内容";

}

<?xml version="1.0" encoding="GBK"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

<context:component-scan base-package="org.crazyit.app.service

,org.crazyit.app.advice">

<context:include-filter type="annotation"

expression="org.aspectj.lang.annotation.Aspect"/>

</context:component-scan>

<aop:aspectj-autoproxy/>

</beans>public class BeanTest

{

public static void main(String[] args)

{

// 创建 Spring 容器

ApplicationContext ctx = new

ClassPathXmlApplicationContext("bean.xml");

Chinese p = ctx.getBean("chinese" ,Chinese.class);

System.out.println(p.sayHello("张三"));

p.eat("西瓜");

}

显示更多

从上面开发过程可以看出，对于 Spring AOP 而言，开发者提供的业务组件、方面 Bean 并没有任何特

别的地方。只是方面 Bean 需要使用 @Aspect 修饰即可。程序不需要使用特别的编译器、织入器进行处

理。

运行上面程序，将可以看到如下执行结果：

执行目标方法之前，模拟开始事务 …

— 正在执行 sayHello 方法 —

执行目标方法之后，模拟结束事务 …

获取目标方法返回值 : 被改变的参数 Hello , Spring AOP 新增的内容

模拟记录日志功能 …

被改变的参数 Hello , Spring AOP 新增的内容

执行目标方法之前，模拟开始事务 …

我正在吃 : 被改变的参数

执行目标方法之后，模拟结束事务 …

获取目标方法返回值 :null 新增的内容

模拟记录日志功能 …

虽然程序是在调用 Chinese 对象的 sayHello、eat 两个方法，但从上面运行结果不难看出：实际执行的

绝对不是 Chinese 对象的方法，而是 AOP 代理的方法。也就是说，Spring AOP 同样为 Chinese 类生成

了 AOP 代理类。这一点可通过在程序中增加如下代码看出：

System.out.println(p.getClass());

上面代码可以输出 p 变量所引用对象的实现类，再次执行程序将可以看到上面代码产生 class

org.crazyit.app.service.impl.Chinese$$EnhancerByCGLIB$$290441d2 的输出，这才是 p 变量所引用

的对象的实现类，这个类也就是 Spring AOP 动态生成的 AOP 代理类。从 AOP 代理类的类名可以看

出，AOP 代理类是由 CGLIB 来生成的。

如果将上面程序程序稍作修改：只要让上面业务逻辑类 Chinese 类实现一个任意接口——这种做法更符

合 Spring 所倡导的”面向接口编程”的原则。假设程序为 Chinese 类提供如下 Person 接口，并让

Chinese 类实现该接口：清单 10.Person.java

显示更多

接下来让 BeanTest 类面向 Person 接口、而不是 Chinese 类编程。即将 BeanTest 类改为如下形式：

清单 11.BeanTest.java

显示更多

原来的程序是将面向 Chinese 类编程，现在将该程序改为面向 Person 接口编程，再次运行该程序，程

序运行结果没有发生改变。只是 System.out.println(p.getClass()); 将会输出 class $Proxy7，这说明此

时的 AOP 代理并不是由 CGLIB 生成的，而是由 JDK 动态代理生成的。

Spring AOP 框架对 AOP 代理类的处理原则是：如果目标对象的实现类实现了接口，Spring AOP 将会采

用 JDK 动态代理来生成 AOP 代理类；如果目标对象的实现类没有实现接口，Spring AOP 将会采用

CGLIB 来生成 AOP 代理类——不过这个选择过程对开发者完全透明、开发者也无需关心。

Spring AOP 会动态选择使用 JDK 动态代理、CGLIB 来生成 AOP 代理，如果目标类实现了接口，Spring

AOP 则无需 CGLIB 的支持，直接使用 JDK 提供的 Proxy 和 InvocationHandler 来生成 AOP 代理即可。

关于如何 Proxy 和 InvocationHandler 来生成动态代理不在本文介绍范围之内，如果读者对 Proxy 和

InvocationHandler 的用法感兴趣则可自行参考 Java API 文档或《疯狂 Java 讲义》。

Spring AOP 原理剖析

通过前面介绍可以知道：AOP 代理其实是由 AOP 框架动态生成的一个对象，该对象可作为目标对象使

用。AOP 代理包含了目标对象的全部方法，但 AOP 代理中的方法与目标对象的方法存在差异：AOP 方

法在特定切入点添加了增强处理，并回调了目标对象的方法。

AOP 代理所包含的方法与目标对象的方法示意图如图 3 所示。

图 3.AOP 代理的方法与目标对象的方法

public interface Person

{

String sayHello(String name);

void eat(String food);

}

public class BeanTest

{

public static void main(String[] args)

{

// 创建 Spring 容器

ApplicationContext ctx = new

ClassPathXmlApplicationContext("bean.xml");

Person p = ctx.getBean("chinese" ,Person.class);

System.out.println(p.sayHello("张三"));

p.eat("西瓜");

System.out.println(p.getClass());

}

}Spring 的 AOP 代理由 Spring 的 IoC 容器负责生成、管理，其依赖关系也由 IoC 容器负责管理。因此，

AOP 代理可以直接使用容器中的其他 Bean 实例作为目标，这种关系可由 IoC 容器的依赖注入提供。

纵观 AOP 编程，其中需要程序员参与的只有 3 个部分：

定义普通业务组件。

定义切入点，一个切入点可能横切多个业务组件。

定义增强处理，增强处理就是在 AOP 框架为普通业务组件织入的处理动作。

上面 3 个部分的第一个部分是最平常不过的事情，无须额外说明。那么进行 AOP 编程的关键就是定义

切入点和定义增强处理。一旦定义了合适的切入点和增强处理，AOP 框架将会自动生成 AOP 代理，而

AOP 代理的方法大致有如下公式：

代理对象的方法 = 增强处理 + 被代理对象的方法

在上面这个业务定义中，不难发现 Spring AOP 的实现原理其实很简单：AOP 框架负责动态地生成 AOP

代理类，这个代理类的方法则由 Advice 和回调目标对象的方法所组成。

对于前面提到的图 2 所示的软件调用结构：当方法 1、方法 2、方法 3……都需要去调用某个具有”横切”

性质的方法时，传统的做法是程序员去手动修改方法 1、方法 2、方法 3……、通过代码来调用这个具有”

横切”性质的方法，但这种做法的可扩展性不好，因为每次都要改代码。

于是 AOP 框架出现了，AOP 框架则可以”动态的”生成一个新的代理类，而这个代理类所包含的方法 1、

方法 2、方法 3……也增加了调用这个具有”横切”性质的方法——但这种调用由 AOP 框架自动生成的代理

类来负责，因此具有了极好的扩展性。程序员无需手动修改方法 1、方法 2、方法 3 的代码，程序员只

要定义切入点即可—— AOP 框架所生成的 AOP 代理类中包含了新的方法 1、访法 2、方法 3，而 AOP

框架会根据切入点来决定是否要在方法 1、方法 2、方法 3 中回调具有”横切”性质的方法。

简而言之：AOP 原理的奥妙就在于动态地生成了代理类，这个代理类实现了图 2 的调用——这种调用无

需程序员修改代码。接下来介绍的 CGLIB 就是一个代理生成库，下面介绍如何使用 CGLIB 来生成代理

类。

使用 CGLIB 生成代理类

CGLIB（Code Generation Library），简单来说，就是一个代码生成类库。它可以在运行时候动态是生

成某个类的子类。

此处使用前面定义的 Chinese 类，现在改为直接使用 CGLIB 来生成代理，这个代理类同样可以实现

Spring AOP 代理所达到的效果。

下面先为 CGLIB 提供一个拦截器实现类：清单 12.AroundAdvice.java

显示更多

上面这个 AroundAdvice.java 的作用就像前面介绍的 Around Advice，它可以在调用目标方法之前、调

用目标方法之后织入增强处理。

接下来程序提供一个 ChineseProxyFactory 类，这个 ChineseProxyFactory 类会通过 CGLIB 来为

Chinese 生成代理类：

清单 13.ChineseProxyFactory.java

显示更多

上面粗体字代码就是使用 CGLIB 的 Enhancer 生成代理对象的关键代码，此时的 Enhancer 将以

Chinese 类作为目标类，以 AroundAdvice 对象作为”Advice”，程序将会生成一个 Chinese 的子类，这

个子类就是 CGLIB 生成代理类，它可作为 Chinese 对象使用，但它增强了 Chinese 类的方法。

测试 Chinese 代理类的主程序如下：

清单 14.Main.java

public class AroundAdvice implements MethodInterceptor

{

public Object intercept(Object target, Method method

, Object[] args, MethodProxy proxy)

throws java.lang.Throwable

{

System.out.println("执行目标方法之前，模拟开始事务 ...");

// 执行目标方法，并保存目标方法执行后的返回值

Object rvt = proxy.invokeSuper(target, new String[]{"被改变的参数"});

System.out.println("执行目标方法之后，模拟结束事务 ...");

return rvt + " 新增的内容";

}

public class ChineseProxyFactory

{

public static Chinese getAuthInstance()

{

Enhancer en = new Enhancer();

// 设置要代理的目标类

en.setSuperclass(Chinese.class);

// 设置要代理的拦截器

en.setCallback(new AroundAdvice());

// 生成代理类的实例

return (Chinese)en.create();

}

}显示更多

运行上面主程序，看到如下输出结果：

执行目标方法之前，模拟开始事务 …

— 正在执行 sayHello 方法 —

执行目标方法之后，模拟结束事务 …

被改变的参数 Hello , CGLIB 新增的内容

执行目标方法之前，模拟开始事务 …

我正在吃 : 被改变的参数

执行目标方法之后，模拟结束事务 …

class lee.Chinese$$EnhancerByCGLIB$$4bd097d9

从上面输出结果来看，CGLIB 生成的代理完全可以作为 Chinese 对象来使用，而且 CGLIB 代理对象的

sayHello()、eat() 两个方法已经增加了事务控制（只是模拟），这个 CGLIB 代理其实就是 Spring AOP

所生成的 AOP 代理。

通过程序最后的输出，不难发现这个代理对象的实现类是

lee.Chinese$$EnhancerByCGLIB$$4bd097d9，这就是 CGLIB 所生成的代理类，这个代理类的格式与

前面 Spring AOP 所生成的代理类的格式完全相同。

这就是 Spring AOP 的根本所在：Spring AOP 就是通过 CGLIB 来动态地生成代理对象，这个代理对象

就是所谓的 AOP 代理，而 AOP 代理的方法则通过在目标对象的切入点动态地织入增强处理，从而完成

了对目标方法的增强。

结束语

AOP 广泛应用于处理一些具有横切性质的系统级服务，AOP 的出现是对 OOP 的良好补充，它使得开发

者能用更优雅的方式处理具有横切性质的服务。不管是那种 AOP 实现，不论是 AspectJ、还是 Spring

AOP，它们都需要动态地生成一个 AOP 代理类，区别只是生成 AOP 代理类的时机不同：AspectJ 采用

编译时生成 AOP 代理类，因此具有更好的性能，但需要使用特定的编译器进行处理；而 Spring AOP 则

采用运行时生成 AOP 代理类，因此无需使用特定编译器进行处理。由于 Spring AOP 需要在每次运行时

生成 AOP 代理，因此性能略差一些。

public class Main

{

public static void main(String[] args)

{

Chinese chin = ChineseProxyFactory.getAuthInstance();

System.out.println(chin.sayHello("孙悟空"));

chin.eat("西瓜");

System.out.println(chin.getClass());

}

}JDK Proxy

Cglib Proxy

只能代理接口

以继承的方式完成代理，不能代理被final修饰的类

JDK Proxy

Cglib Proxy

生成代理类时间

1'060.766

960.527

方法调用时间

0.008

0.003

来源

JDK原生代码

第三方库，更新频率较低

spring AOP 两种代理方式

回答为什么要用什么方法这种问题的时候，通常首先要回答两个问题，第一个就是，我要做什么事情，

第二个就是，不同方法的优劣是什么。

首先，我要做什么事情。

这里的回答比较简单，就是代理Java类/接口。那么，两者在完成这件事情上，有什么差别呢

实际上，大部分的Java类都会以接口-实现的方式来完成，因此，在这个方面上，JDK Proxy实际上是比

Cglib Proxy要更胜一筹的。因为如果一个类被final修饰，则Cglib Proxy无法进行代理。

其次，两种方法的优劣又在什么地方呢？

我们可以参考一下来自bytebuddy的数据，这个是在代理一个实现了具有18个方法的接口的类，时间单

位为ns。

不难看出，其实Cglib代理的性能是要远远好于JDK代理的。

其实从原理也能理解，直接通过类的方法调用，肯定要比通过反射调用的时间更短。但是从来源来看的

话，一个是JDK原生代码，而另一个则是第三方的开源库。JDK原生代码无疑使用的人会更多范围也更

广，会更佳稳定，而且还有可能在未来的JDK版本中不断优化性能。

而Cglib更新频率相对来说比较低了，一方面是因为这个代码库已经渐趋稳定，另一方面也表明后续这个

库可能相对来说不会有大动作的优化维护。

对比完之后，再来回看这个问题，为什么要使用两种方式呢？

在功能上讲，实际上Cglib代理并不如JDK代理（如果大家都按接口-实现的方式来设计类）。但是从效率

上将，Cglib远胜JDK代理啊！所以，为了提高效率，同时又保有在未来，当JDK代理的性能也能够同样好

的时候，使用更佳稳定靠谱的JDK代码，这种可能，于是采取了这种设计。

Spring 如何保证 Controller 并发的安全？springMVC一个Controller处理所有用户请求的并发问题

有状态和无状态的对象基本概念：

有状态对象(Stateful Bean)，就是有实例变量的对象，可以保存数据，是非线程安全的。一般是

prototype scope。

无状态对象(Stateless Bean)，就是没有实例变量的对象，不能保存数据，是不变类，是线程安全的。一

般是singleton scope。

如Struts2中的Action，假如内部有实例变量User，当调用新增用户方法时，user是用来保存数据，那么

此action是有状态对象。多个线程同时访问此action时会造成user变量的不一致。所以action的scope

要设计成prototype，或者，User类放到threadLocal里来保持多个线程不会造成User变量的乱串（此种

场景没必要放到threadLocal内）。

而Service内部一般只有dao实例变量如userDao, 因为userDao是无状态的对象（内部无实例变量且不

能保存数据），所以service也是无状态的对象。

*public class* XxxAction{

// 由于多线程环境下，user是引用对象，是非线程安全的

*public* User user;

......

}

*public class* XxxService {

// 虽然有billDao属性，但billDao是没有状态信息的，是Stateless Bean.

BillDao billDao;

......

}

对于那些会以多线程运行的单例类

局部变量不会受多线程影响，

成员变量会受到多线程影响。

多个线程调用同一个对象的同一个方法：

如果方法里无局部变量，那么不受任何影响；

如果方法里有局部变量，只有读操作，不受影响；存在写操作，考虑多线程影响值；

例如Web应用中的Servlet，每个方法中对局部变量的操作都是在线程自己独立的内存区域内完成的，所

以是线程安全的。

对于成员变量的操作，可以使用ThreadLocal来保证线程安全。

springMVC中，一般Controller、service、DAO层的scope均是singleton；

每个请求都是单独的线程,即使同时访问同一个Controller对象，因为并没有修改Controller对象，相当

于针对Controller对象而言，只是读操作，没有写操作，不需要做同步处理。

Service层、Dao层用默认singleton就行，虽然Service类也有dao这样的属性，但dao这些类都是没有状

态信息的，也就是相当于不变(immutable)类，所以不影响。Struts2中的Action因为会有User、BizEntity这样的实例对象，是有状态信息的，在多线程环境下是不

安全的，所以Struts2默认的实现是Prototype模式。在Spring中，Struts2的Action中scope 要配成

prototype作用域。

Spring并发访问的线程安全性问题

由于Spring MVC默认是Singleton的，所以会产生一个潜在的安全隐患。根本核心是instance变量保持

状态的问题。这意味着每个request过来，系统都会用原有的instance去处理，这样导致了两个结果：

一是我们不用每次创建Controller，

二是减少了对象创建和垃圾收集的时间；

由于只有一个Controller的instance，当多个线程同时调用它的时候，它里面的instance变量就不是线程

安全的了，会发生窜数据的问题。

当然大多数情况下，我们根本不需要考虑线程安全的问题，比如dao,service等，除非在bean中声明了实

例变量。因此，我们在使用spring mvc 的contrller时，应避免在controller中定义实例变量。

如：

在这里有声明一个变量company，这里就存在并发线程安全的问题。

如果控制器是使用单例形式，且controller中有一个私有的变量a,所有请求到同一个controller时，使用

的a变量是共用的，即若是某个请求中修改了这个变量a，则，在别的请求中能够读到这个修改的内

容。。

有几种解决方法：

1、在控制器中不使用实例变量

2、将控制器的作用域从单例改为原型，即在spring配置文件Controller中声明 scope="prototype"，每

次都创建新的controller

3、在Controller中使用ThreadLocal变量

这几种做法有好有坏，第一种，需要开发人员拥有较高的编程水平与思想意识，在编码过程中力求避免

出现这种BUG，而第二种则是容器自动的对每个请求产生一个实例，由JVM进行垃圾回收，因此做到了

线程安全。

使用第一种方式的好处是实例对象只有一个，所有的请求都调用该实例对象，速度和性能上要优于第二

种，不好的地方，就是需要程序员自己去控制实例变量的状态保持问题。第二种由于每次请求都创建一

个实例，所以会消耗较多的内存空间。

所以在使用spring开发web 时要注意，默认Controller、Dao、Service都是单例的

publicclassControllerextendsAbstractCommandController{

......

protectedModelAndView handle(HttpServletRequest request,HttpServletResponse

response,

Object command,BindException errors)throwsException{

company =................;

}

protectedCompany company;

}spring中用到哪些设计模式？

1.工厂模式，这个很明显，在各种BeanFactory以及ApplicationContext创建中都用到了；

2.模版模式，这个也很明显，在各种BeanFactory以及ApplicationContext实现中也都用到了；

3.代理模式，在Aop实现中用到了JDK的动态代理；

4.单例模式，这个比如在创建bean的时候。

5.Tomcat中有很多场景都使用到了外观模式，因为Tomcat中有很多不同的组件，每个组件需要相互通

信，但又不能将自己内部数据过多地暴露给其他组件。用外观模式隔离数据是个很好的方法。

6.策略模式在Java中的应用，这个太明显了，因为Comparator这个接口简直就是为策略模式而生的。

Comparable和Comparator的区别一文中，详细讲了Comparator的使用。比方说Collections里面有一

个sort方法，因为集合里面的元素有可能是复合对象，复合对象并不像基本数据类型，可以根据大小排

序，复合对象怎么排序呢？基于这个问题考虑，Java要求如果定义的复合对象要有排序的功能，就自行

实现Comparable接口或Comparator接口.

7.原型模式：使用原型模式创建对象比直接new一个对象在性能上好得多，因为Object类的clone()方法

是一个native方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。

8.迭代器模式：Iterable接口和Iterator接口这两个都是迭代相关的接口，可以这么认为，实现了

Iterable接口，则表示某个对象是可被迭代的；Iterator接口相当于是一个迭代器，实现了Iterator接

口，等于具体定义了这个可被迭代的对象时如何进行迭代的

Spring IOC 的理解，其初始化过程？

IoC容器是什么？

IoC文英全称Inversion of Control，即控制反转，我么可以这么理解IoC容器：

“把某些业务对象的的控制权交给一个平台或者框架来同一管理，这个同一管理的平台可以称为IoC

容器。”

我们刚开始学习spring的时候会经常看到的类似下面的这代码：

上面代码中，在创建ApplicationContext实例对象过程中会创建一个spring容器，该容器会读取配置文

件"cjj/models/beans.xml",并统一管理由该文件中定义好的所有bean实例对象，如果要获取某个bean

实例，使用getBean方法就行了。例如我们只需要将Person提前配置在beans.xml文件中（可以理解为

注入），之后我们可以不需使用new Person()的方式创建实例，而是通过容器来获取Person实例，这就

相当于将Person的控制权交由spring容器了，差不多这就是控制反转的概念。

那在创建IoC容器时经历了哪些呢？为此，先来了解下Spring中IoC容器分类，继而根据一个具体的容器

来讲解IoC容器初始化的过程。

Spring中有两个主要的容器系列：

1. 实现BeanFactory接口的简单容器；

2. 实现ApplicationContext接口的高级容器。

ApplicationContext appContext = new

ClassPathXmlApplicationContext("cjj/models/beans.xml");

Person p = (Person)appContext.getBean("person");ApplicationContext比较复杂，它不但继承了BeanFactory的大部分属性，还继承其它可扩展接口，扩

展的了许多高级的属性，其接口定义如下：

public interface ApplicationContext extends EnvironmentCapable,

ListableBeanFactory, //继承于

BeanFactory HierarchicalBeanFactory,//继承于

BeanFactory

MessageSource,

ApplicationEventPublisher,// ResourcePatternResolver

//继承ResourceLoader，用于获取resource对象

在BeanFactory子类中有一个DefaultListableBeanFactory类，它包含了基本Spirng IoC容器所具有的

重要功能，开发时不论是使用BeanFactory系列还是ApplicationContext系列来创建容器基本都会使用

到DefaultListableBeanFactory类，可以这么说，在spring中实际上把它当成默认的IoC容器来使用。下

文在源码实例分析时你将会看到这个类。

（注：文章有点长，需要细心阅读，不同版本的spring中源码可能不同，但逻辑几乎是一样的，如果可

以建议还是看源码 ^_^）

回到本文正题上来，关于Spirng IoC容器的初始化过程在《Spirng技术内幕：深入解析Spring架构与设

计原理》一书中有明确的指出，IoC容器的初始化过程可以分为三步：

1. Resource定位（Bean的定义文件定位）

2. 将Resource定位好的资源载入到BeanDefinition

3. 将BeanDefiniton注册到容器中

第一步 Resource定位

Resource是Sping中用于封装I/O操作的接口。正如前面所见，在创建spring容器时，通常要访问XML配

置文件，除此之外还可以通过访问文件类型、二进制流等方式访问资源，还有当需要网络上的资源时可

以通过访问URL，Spring把这些文件统称为Resource，Resource的体系结构如下:

常用的resource资源类型如下：

FileSystemResource：以文件的绝对路径方式进行访问资源，效果类似于Java中的File;

ClassPathResourcee：以类路径的方式访问资源，效果类似于

this.getClass().getResource("/").getPath();ServletContextResource：web应用根目录的方式访问资源，效果类似于

request.getServletContext().getRealPath("");

UrlResource：访问网络资源的实现类。例如file: http: ftp:等前缀的资源对象;

ByteArrayResource: 访问字节数组资源的实现类。

那如何获取上图中对应的各种Resource对象呢？

Spring提供了ResourceLoader接口用于实现不同的Resource加载策略，该接口的实例对象中可以获取

一个resource对象，也就是说将不同Resource实例的创建交给ResourceLoader的实现类来处理。

ResourceLoader接口中只定义了两个方法：

Resource getResource(String location); //通过提供的资源location参数获取Resource实例

ClassLoader getClassLoader(); // 获取ClassLoader,通过ClassLoader可将资源载入JVM

注：ApplicationContext的所有实现类都实现RecourceLoader接口，因此可以直接调用

getResource（参数）获取Resoure对象。不同的ApplicatonContext实现类使用getResource方法取得

的资源类型不同，例如：FileSystemXmlApplicationContext.getResource获取的就是

FileSystemResource实例；ClassPathXmlApplicationContext.gerResource获取的就是

ClassPathResource实例；XmlWebApplicationContext.getResource获取的就是

ServletContextResource实例，另外像不需要通过xml直接使用注解@Configuation方式加载资源的

AnnotationConfigApplicationContext等等。

在资源定位过程完成以后，就为资源文件中的bean的载入创造了I/O操作的条件，如何读取资源中的数

据将会在下一步介绍的BeanDefinition的载入过程中描述。

*第二步通过返回的*resource对象，进行BeanDefinition的载入

1.什么是BeanDefinition? BeanDefinition与Resource的联系呢？

官方文档中对BeanDefinition的解释如下：

A BeanDefinition describes a bean instance, which has property values, constructor argument

values, and further information supplied by concrete implementations.

它们之间的联系从官方文档描述的一句话：Load bean definitions from the specified resource中可见

一斑。

/**

* Load bean definitions from the specified resource.

* @param resource the resource descriptor

* @return the number of bean definitions found

* @throws BeanDefinitionStoreException in case of loading or parsing errors

int loadBeanDefinitions(Resource resource) throws

BeanDefinitionStoreException;

总之，BeanDefinition相当于一个数据结构，这个数据结构的生成过程是根据定位的resource资源

对象中的bean而来的，这些bean在Spirng IoC容器内部表示成了的BeanDefintion这样的数据结构，

IoC容器对bean的管理和依赖注入的实现都是通过操作BeanDefinition来进行的。

2.如何将BeanDefinition载入到容器？

在Spring中配置文件主要格式是XML，对于用来读取XML型资源文件来进行初始化的IoC 容器而

言，该类容器会使用到AbstractXmlApplicationContext类，该类定义了一个名为

loadBeanDefinitions(DefaultListableBeanFactory beanFactory) 的方法用于获取BeanDefinition：// 该方法属于AbstractXmlApplicationContect类

protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws

BeansException, IOException {

XmlBeanDefinitionReader beanDefinitionReader = new

XmlBeanDefinitionReader(beanFactory);

beanDefinitionReader.setEnvironment(this.getEnvironment());

beanDefinitionReader.setResourceLoader(this);

beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

this.initBeanDefinitionReader(beanDefinitionReader);

// 用于获取BeanDefinition

this.loadBeanDefinitions(beanDefinitionReader);

}

此方法在具体执行过程中首先会new一个与容器对应的BeanDefinitionReader型实例对象，然后将生成

的BeanDefintionReader实例作为参数传入loadBeanDefintions(XmlBeanDefinitionReader)，继续往

下执行载入BeanDefintion的过程。例如AbstractXmlApplicationContext有两个实现类：

FileSystemXmlApplicationContext、ClassPathXmlApplicationContext，这些容器在调用此方法时会

创建一个XmlBeanDefinitionReader类对象专门用来载入所有的BeanDefinition。

下面以XmlBeanDefinitionReader对象载入BeanDefinition为例，使用源码说明载入BeanDefinition的

过程：

// 该方法属于AbstractXmlApplicationContect类protected void

loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException,

IOException {

Resource[] configResources = getConfigResources();//获取所有定位到的

resource资源位置（用户定义）

if (configResources != null) {

reader.loadBeanDefinitions(configResources);//载入resources

}

String[] configLocations = getConfigLocations();//获取所有本地配置文件的位置

（容器自身）

if (configLocations != null) {

reader.loadBeanDefinitions(configLocations);//载入resources

}

通过上面代码将用户定义的资源以及容器本身需要的资源全部加载到reader中，

reader.loadBeanDefinitions方法的源码如下：// 该方法属于AbstractBeanDefinitionReader类, 父接口BeanDefinitionReader

@Override

public int loadBeanDefinitions(Resource... resources) throws

BeanDefinitionStoreException {

Assert.notNull(resources, "Resource array must not be null");

int counter = 0;

for (Resource resource : resources) {

// 将所有资源全部加载，交给AbstractBeanDefinitionReader的实现子类处理这些

resource

counter += loadBeanDefinitions(resource);

}

return counter;

}

BeanDefinitionReader接口定义了 int loadBeanDefinitions（Resource resource）方法：

int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException;

int loadBeanDefinitions(Resource... resources) throws

BeanDefinitionStoreException;

XmlBeanDefinitionReader 类实现了BeanDefinitionReader接口中的loadBeanDefinitions(Resource)

方法，其继承关系如上图所示。XmlBeanDefinitionReader类中几主要对加载的所有resource开始进行

处理，大致过程是，先将resource包装为EncodeResource类型，然后处理，为生成BeanDefinition对

象做准备，其主要几个方法的源码如下：

public int loadBeanDefinitions(Resource resource) throws

BeanDefinitionStoreException {

// 包装resource为EncodeResource类型

return loadBeanDefinitions(new EncodedResource(resource));

}

// 加载包装后的EncodeResource资源

public int loadBeanDefinitions(EncodedResource encodedResource) throws

BeanDefinitionStoreException {

Assert.notNull(encodedResource, "EncodedResource must not be null");

if (logger.isInfoEnabled()) {

logger.info("Loading XML bean definitions from " +

encodedResource.getResource());

}try {

// 通过resource对象得到XML文件内容输入流，并为IO的InputSource做准备

InputStream inputStream =

encodedResource.getResource().getInputStream();

try {

// Create a new input source with a byte stream.

InputSource inputSource = new InputSource(inputStream);

if (encodedResource.getEncoding() != null) {

inputSource.setEncoding(encodedResource.getEncoding());

}

// 开始准备 load bean definitions from the specified XML file

return doLoadBeanDefinitions(inputSource,

encodedResource.getResource());

}

finally {

inputStream.close();

}

catch (IOException ex) {

throw new BeanDefinitionStoreException(

"IOException parsing XML document from " +

encodedResource.getResource(), ex);

}

protected int doLoadBeanDefinitions(InputSource inputSource, Resource

resource)

throws BeanDefinitionStoreException {

try {

// 获取指定资源的验证模式

int validationMode = getValidationModeForResource(resource);

// 从资源对象中加载DocumentL对象，大致过程为：将resource资源文件的内容读入到

document中

// DocumentLoader在容器读取XML文件过程中有着举足轻重的作用！

// XmlBeanDefinitionReader实例化时会创建一个DefaultDocumentLoader型的私有

属性,继而调用loadDocument方法

// inputSource--要加载的文档的输入源

Document doc = this.documentLoader.loadDocument(

inputSource, this.entityResolver, this.errorHandler,

validationMode, this.namespaceAware);

// 将document文件的bean封装成BeanDefinition，并注册到容器

return registerBeanDefinitions(doc, resource);

}

catch ...(略)

}

DefaultDocumentLoader大致了解即可，感兴趣可继续深究，其源码如下：（看完收起，便于阅读下

文）

View Code

上面代码分析到了registerBeanDefinitions(doc, resource)这一步，也就是准备将Document中的Bean

按照Spring bean语义进行解析并转化为BeanDefinition类型，这个方法的具体过程如下：/**

* 属于XmlBeanDefinitionReader类

* Register the bean definitions contained in the given DOM document.

* @param doc the DOM document

* @param resource

* @return the number of bean definitions found

* @throws BeanDefinitionStoreException

public int registerBeanDefinitions(Document doc, Resource resource) throws

BeanDefinitionStoreException {

// 获取到DefaultBeanDefinitionDocumentReader实例

BeanDefinitionDocumentReader documentReader =

createBeanDefinitionDocumentReader();

// 获取容器中bean的数量

int countBefore = getRegistry().getBeanDefinitionCount();

documentReader.registerBeanDefinitions(doc, createReaderContext(resource));

return getRegistry().getBeanDefinitionCount() - countBefore;

}

通过 XmlBeanDefinitionReader 类中的私有属性 documentReaderClass 可以获得一个

DefaultBeanDefinitionDocumentReader 实例对象：

private Class<?> documentReaderClass =

DefaultBeanDefinitionDocumentReader.class;

protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {

return

BeanDefinitionDocumentReader.class.cast(BeanUtils.instantiateClass(this.document

ReaderClass));

}

DefaultBeanDefinitionDocumentReader实现了BeanDefinitionDocumentReader接口，它的

registerBeanDefinitions方法定义如下：

// DefaultBeanDefinitionDocumentReader implements BeanDefinitionDocumentReader

public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext)

{

this.readerContext = readerContext;

logger.debug("Loading bean definitions");

// 获取doc的root节点，通过该节点能够访问所有的子节点

Element root = doc.getDocumentElement();

// 处理beanDefinition的过程委托给BeanDefinitionParserDelegate实例对象来完成

BeanDefinitionParserDelegate delegate = createHelper(readerContext, root);

// Default implementation is empty.

// Subclasses can override this method to convert custom elements into

standard Spring bean definitions

preProcessXml(root);

// 核心方法，代理

parseBeanDefinitions(root, delegate);postProcessXml(root);

}

上面出现的BeanDefinitionParserDelegate类非常非常重要（需要了解代理技术，如JDK动态代理、

cglib动态代理等）。Spirng BeanDefinition的解析就是在这个代理类下完成的，此类包含了各种对符合

Spring Bean语义规则的处理，比如、、等的检测。

parseBeanDefinitions(root, delegate)方法如下：

protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate

delegate) {

if (delegate.isDefaultNamespace(root)) {

NodeList nl = root.getChildNodes();

// 遍历所有节点，做对应解析工作

// 如遍历到<import>标签节点就调用importBeanDefinitionResource(ele)方法对应

处理

// 遍历到<bean>标签就调用processBeanDefinition(ele,delegate)方法对应处理

for (int i = 0; i < nl.getLength(); i++) {

Node node = nl.item(i);

if (node instanceof Element) {

Element ele = (Element) node;

if (delegate.isDefaultNamespace(ele)) {

parseDefaultElement(ele, delegate);

}

else {

//对应用户自定义节点处理方法

delegate.parseCustomElement(ele);

}

else {

delegate.parseCustomElement(root);

}

private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate

delegate) {

// 解析<import>标签

if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {

importBeanDefinitionResource(ele);

}

// 解析<alias>标签

else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {

processAliasRegistration(ele);

}

// 解析<bean>标签,最常用，过程最复杂

else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {

processBeanDefinition(ele, delegate);

}

// 解析<beans>标签

else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {

// recurse

doRegisterBeanDefinitions(ele);}

}

这里针对常用的标签中的方法做简单介绍，其他标签的加载方式类似：

/**

* Process the given bean element, parsing the bean definition

* and registering it with the registry.

protected void processBeanDefinition(Element ele,

BeanDefinitionParserDelegate delegate) {

// 该对象持有beanDefinition的name和alias，可以使用该对象完成beanDefinition向容

器的注册

BeanDefinitionHolder bdHolder =

delegate.parseBeanDefinitionElement(ele);

if (bdHolder != null) {

bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);

try {

// 注册最终被修饰的bean实例，下文注册beanDefinition到容器会讲解该方法

BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder,

getReaderContext().getRegistry());

}

catch (BeanDefinitionStoreException ex) {

getReaderContext().error("Failed to register bean definition with

name '" +

bdHolder.getBeanName() + "'", ele, ex);

}

// Send registration event.

getReaderContext().fireComponentRegistered(new

BeanComponentDefinition(bdHolder));

}

parseBeanDefinitionElement(Element ele)方法会调用parseBeanDefinitionElement(ele, null)方法，

并将值返回BeanDefinitionHolder类对象，这个方法将会对给定的标签进行解析，如果在解析标签的

过程中出现错误则返回null。

需要强调一下的是parseBeanDefinitionElement(ele, null)方法中产生了一个抽象类型的BeanDefinition

实例，这也是我们首次看到直接定义BeanDefinition的地方，这个方法里面会将标签中的内容解析到

BeanDefinition中，之后再对BeanDefinition进行包装，将它与beanName,Alias等封装到

BeanDefinitionHolder 对象中，该部分源码如下：

public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) {

return parseBeanDefinitionElement(ele, null);

}

public BeanDefinitionHolder parseBeanDefinitionElement(Element ele,

BeanDefinition containingBean) {

String id = ele.getAttribute(ID_ATTRIBUTE);String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);

...(略)

String beanName = id;

...（略）

// 从上面按过程走来，首次看到直接定义BeanDefinition ！！！

// 该方法会对<bean>节点以及其所有子节点如<property>、<List>、<Set>等做出解析，具

体过程本文不做分析（太多太长）

AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele,

beanName, containingBean);

if (beanDefinition != null) {

if (!StringUtils.hasText(beanName)) {

...(略)

}

String[] aliasesArray = StringUtils.toStringArray(aliases);

return new BeanDefinitionHolder(beanDefinition, beanName,

aliasesArray);

}

return null;

}

第三步，将BeanDefiniton注册到容器中

最终Bean配置会被解析成BeanDefinition并与beanName,Alias一同封装到BeanDefinitionHolder

类中，之后beanFactory.registerBeanDefinition(beanName, bdHolder.getBeanDefinition())，注册

到DefaultListableBeanFactory.beanDefinitionMap中。之后客户端如果要获取Bean对象，Spring容

器会根据注册的BeanDefinition信息进行实例化。

BeanDefinitionReaderUtils类：

public static void registerBeanDefinition(

BeanDefinitionHolder bdHolder, BeanDefinitionRegistry beanFactory)

throws BeansException {

// Register bean definition under primary name.

String beanName = bdHolder.getBeanName(); // 注册beanDefinition!!!

beanFactory.registerBeanDefinition(beanName,

bdHolder.getBeanDefinition());

// 如果有别名的话也注册进去，Register aliases for bean name, if any.

String[] aliases = bdHolder.getAliases();

if (aliases != null) {

for (int i = 0; i < aliases.length; i++) {

beanFactory.registerAlias(beanName, aliases[i]);

}

}DefaultListableBeanFactory实现了上面调用BeanDefinitionRegistry接口的

registerBeanDefinition( beanName, bdHolder.getBeanDefinition())方法，这一部分的主要逻辑是向

DefaultListableBeanFactory对象的beanDefinitionMap中存放beanDefinition，当初始化容器进行

bean初始化时，在bean的生命周期分析里必然会在这个beanDefinitionMap中获取beanDefition实

例，有机会成文分析一下bean的生命周期，到时可以分析一下如何使用这个beanDefinitionMap。

registerBeanDefinition( beanName, bdHolder.getBeanDefinition() )方法具体方法如下：

/** Map of bean definition objects, keyed by bean name */

private final Map<String, BeanDefinition> beanDefinitionMap = new

ConcurrentHashMap<String, BeanDefinition>(256);

public void registerBeanDefinition(String beanName, BeanDefinition

beanDefinition)

throws BeanDefinitionStoreException {

Assert.hasText(beanName, "Bean name must not be empty");

Assert.notNull(beanDefinition, "Bean definition must not be null");

if (beanDefinition instanceof AbstractBeanDefinition) {

try {

((AbstractBeanDefinition) beanDefinition).validate();

}

catch (BeanDefinitionValidationException ex) {

throw new

BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,

"Validation of bean definition failed", ex);

}

// beanDefinitionMap是个ConcurrentHashMap类型数据，用于存放

beanDefinition,它的key值是beanName

Object oldBeanDefinition = this.beanDefinitionMap.get(beanName);

if (oldBeanDefinition != null) {

if (!this.allowBeanDefinitionOverriding) {

throw new

BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,

"Cannot register bean definition [" + beanDefinition + "]

for bean '" + beanName +

"': there's already [" + oldBeanDefinition + "] bound");

}

else {

if (logger.isInfoEnabled()) {

logger.info("Overriding bean definition for bean '" +

beanName +

"': replacing [" + oldBeanDefinition + "] with [" +

beanDefinition + "]");

}

else {

this.beanDefinitionNames.add(beanName);

} // 将获取到的BeanDefinition放入Map中，容器操作使用bean时通过这个

HashMap找到具体的BeanDefinitionSpring的事务管理

1 初步理解

理解事务之前，先讲一个你日常生活中最常干的事：取钱。

比如你去ATM机取1000块钱，大体有两个步骤：首先输入密码金额，银行卡扣掉1000元钱；然后ATM

出1000元钱。这两个步骤必须是要么都执行要么都不执行。如果银行卡扣除了1000块但是ATM出钱失

败的话，你将会损失1000元；如果银行卡扣钱失败但是ATM却出了1000块，那么银行将损失1000元。

所以，如果一个步骤成功另一个步骤失败对双方都不是好事，如果不管哪一个步骤失败了以后，整个取

钱过程都能回滚，也就是完全取消所有操作的话，这对双方都是极好的。

事务就是用来解决类似问题的。事务是一系列的动作，它们综合在一起才是一个完整的工作单元，这些

动作必须全部完成，如果有一个失败的话，那么事务就会回滚到最开始的状态，仿佛什么都没发生过一

样。

在企业级应用程序开发中，事务管理必不可少的技术，用来确保数据的完整性和一致性。

事务有四个特性：ACID

原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要

么全部完成，要么完全不起作用。

一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业

务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。

隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他

事务隔离开来，防止数据损坏。

持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影

响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器

中。

2 核心接口

Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下

面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。

Spring事务管理涉及的接口的联系如下：

this.beanDefinitionMap.put(beanName, beanDefinition); // Remove

corresponding bean from singleton cache, if any.

// Shouldn't usually be necessary, rather just meant for overriding

// a context's default beans (e.g. the default StaticMessageSource

// in a StaticApplicationContext).

removeSingleton(beanName);

}2.1 事务管理器

Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者

JTA等持久化机制所提供的相关平台框架的事务来实现。

Spring事务管理器的接口是org.springframework.transaction.PlatformTransactionManager，通过这

个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各

个平台自己的事情了。此接口的内容如下：

从这里可知具体的具体的事务管理机制对Spring来说是透明的，它并不关心那些，那些是对应各个平台

需要关心的，所以Spring事务管理的一个优点就是为不同的事务API提供一致的编程模型，如JTA、

JDBC、Hibernate、JPA。下面分别介绍各个平台框架实现事务管理的机制。

2.1.1 JDBC事务

如果应用程序中直接使用JDBC来进行持久化，DataSourceTransactionManager会为你处理事务边界。

为了使用DataSourceTransactionManager，你需要使用如下的XML将其装配到应用程序的上下文定义

中：

实际上，DataSourceTransactionManager是通过调用java.sql.Connection来管理事务，而后者是通过

DataSource获取到的。通过调用连接的commit()方法来提交事务，同样，事务失败则通过调用

rollback()方法进行回滚。

Public interface PlatformTransactionManager()...{

// 由TransactionDefinition得到TransactionStatus对象

TransactionStatus getTransaction(TransactionDefinition definition) throws

TransactionException;

// 提交

Void commit(TransactionStatus status) throws TransactionException;

// 回滚

Void rollback(TransactionStatus status) throws TransactionException;

}

<bean id="transactionManager"

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

</bean>2.1.2 Hibernate事务

如果应用程序的持久化是通过Hibernate实习的，那么你需要使用HibernateTransactionManager。对

于Hibernate3，需要在Spring上下文定义中添加如下的 <bean> 声明：

sessionFactory属性需要装配一个Hibernate的session工厂，HibernateTransactionManager的实现细

节是它将事务管理的职责委托给org.hibernate.Transaction对象，而后者是从Hibernate Session中获取

到的。当事务成功完成时，HibernateTransactionManager将会调用Transaction对象的commit()方

法，反之，将会调用rollback()方法。

2.1.3 Java持久化API事务（JPA）

Hibernate多年来一直是事实上的Java持久化标准，但是现在Java持久化API作为真正的Java持久化标准

进入大家的视野。如果你计划使用JPA的话，那你需要使用Spring的JpaTransactionManager来处理事

务。你需要在Spring中这样配置JpaTransactionManager：

JpaTransactionManager只需要装配一个JPA实体管理工厂（javax.persistence.EntityManagerFactory

接口的任意实现）。JpaTransactionManager将与由工厂所产生的JPA EntityManager合作来构建事务。

2.1.4 Java原生API事务

如果你没有使用以上所述的事务管理，或者是跨越了多个事务管理源（比如两个或者是多个不同的数据

源），你就需要使用JtaTransactionManager：

JtaTransactionManager将事务管理的责任委托给javax.transaction.UserTransaction和

javax.transaction.TransactionManager对象，其中事务成功完成通过UserTransaction.commit()方法

提交，事务失败通过UserTransaction.rollback()方法回滚。

2.2 基本事务属性的定义

上面讲到的事务管理器接口PlatformTransactionManager通过getTransaction(TransactionDefinition

definition)方法来得到事务，这个方法里面的参数是TransactionDefinition类，这个类就定义了一些基

本的事务属性。

那么什么是事务属性呢？事务属性可以理解成事务的一些基本配置，描述了事务策略如何应用到方法

上。事务属性包含了5个方面，如图所示：

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

<bean id="transactionManager"

class="org.springframework.orm.jpa.JpaTransactionManager">

</bean>

<bean id="transactionManager"

class="org.springframework.transaction.jta.JtaTransactionManager">

<property name="transactionManagerName" value="java:/TransactionManager"

</bean>而TransactionDefinition接口内容如下：

我们可以发现TransactionDefinition正好用来定义事务属性，下面详细介绍一下各个事务属性。

2.2.1 传播行为

事务的第一个方面是传播行为（propagation behavior）。当事务方法被另一个事务方法调用时，必须

指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的

事务中运行。Spring定义了七种传播行为：

public interface TransactionDefinition {

int getPropagationBehavior(); // 返回事务的传播行为

int getIsolationLevel(); // 返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以

看到本事务内的哪些数据

int getTimeout(); // 返回事务必须在多少秒内完成

boolean isReadOnly(); // 事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是

只读的

}传播行为

含义

PROPAGATION_REQUIRED

表示当前方法必须运行在事务中。如果当前事务存在，方

法将会在该事务中运行。否则，会启动一个新的事务

PROPAGATION_SUPPORTS

表示当前方法不需要事务上下文，但是如果存在当前事务

的话，那么该方法会在这个事务中运行

PROPAGATION_MANDATORY

表示该方法必须在事务中运行，如果当前事务不存在，则

会抛出一个异常

PROPAGATION_REQUIRED_NEW

表示当前方法必须运行在它自己的事务中。一个新的事务

将被启动。如果存在当前事务，在该方法执行期间，当前

事务会被挂起。如果使用JTATransactionManager的话，

则需要访问TransactionManager

PROPAGATION_NOT_SUPPORTED

表示该方法不应该运行在事务中。如果存在当前事务，在

该方法运行期间，当前事务将被挂起。如果使用

JTATransactionManager的话，则需要访问

TransactionManager

PROPAGATION_NEVER

表示当前方法不应该运行在事务上下文中。如果当前正有

一个事务在运行，则会抛出异常

PROPAGATION_NESTED

表示如果当前已经存在一个事务，那么该方法将会在嵌套

事务中运行。嵌套的事务可以独立于当前事务进行单独地

提交或回滚。如果当前事务不存在，那么其行为与

PROPAGATION_REQUIRED一样。注意各厂商对这种传播

行为的支持是有所差异的。可以参考资源管理器的文档来

确认它们是否支持嵌套事务

*注：以下具体讲解传播行为的内容参考自Spring事务机制详解

（

1）PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的

事务。

使用spring声明式事务，spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用之前决

定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。

单独调用methodB方法：

//事务属性 PROPAGATION_REQUIRED

methodA{

……

methodB();

……

}

//事务属性 PROPAGATION_REQUIRED

methodB{

……

}

main{

metodB();

}相当于

Main{

Connection con=null;

try{

con = getConnection();

con.setAutoCommit(false);

//方法调用

methodB();

//提交事务

con.commit();

} Catch(RuntimeException ex) {

//回滚事务

con.rollback();

} finally {

//释放资源

closeCon();

}

Spring保证在methodB方法中所有的调用都获得到一个相同的连接。在调用methodB时，没有一个存

在的事务，所以获得一个新的连接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB.

执行效果相当于：

main{

Connection con = null;

try{

con = getConnection();

methodA();

con.commit();

} catch(RuntimeException ex) {

con.rollback();

} finally {

closeCon();

}

调用MethodA时，环境中没有事务，所以开启一个新的事务.当在MethodA中调用MethodB时，环境中

已经有了一个事务，所以methodB就加入当前事务。

（

2）PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执

行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

//事务属性 PROPAGATION_REQUIRED

methodA(){

methodB();

}

//事务属性 PROPAGATION_SUPPORTS

methodB(){

……

}单纯的调用methodB时，methodB方法是非事务的执行的。当调用methdA时,methodB则加入了

methodA的事务中,事务地执行。

（

3）PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事

务，则抛出异常。

//事务属性 PROPAGATION_REQUIRED

methodA(){

methodB();

}

//事务属性 PROPAGATION_MANDATORY

methodB(){

……

}

当单独调用methodB时，因为当前没有一个活动的事务，则会抛出异常throw new

IllegalTransactionStateException(“Transaction propagation ‘mandatory’ but no existing transaction

found”);当调用methodA时，methodB则加入到methodA的事务中，事务地执行。

（

4）PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在

的事务挂起。

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_REQUIRES_NEW

methodB(){

……

}

调用A方法：

main(){

methodA();

}

相当于

main(){

TransactionManager tm = null;

try{

//获得一个JTA事务管理器

tm = getTransactionManager();

tm.begin();//开启一个新的事务

Transaction ts1 = tm.getTransaction();

doSomeThing();

tm.suspend();//挂起当前事务

try{

tm.begin();//重新开启第二个事务

Transaction ts2 = tm.getTransaction();methodB();

ts2.commit();//提交第二个事务

} Catch(RunTimeException ex) {

ts2.rollback();//回滚第二个事务

} finally {

//释放资源

}

//methodB执行完后，恢复第一个事务

tm.resume(ts1);

doSomeThingB();

ts1.commit();//提交第一个事务

} catch(RunTimeException ex) {

ts1.rollback();//回滚第一个事务

} finally {

//释放资源

}

在这里，我把ts1称为外层事务，ts2称为内层事务。从上面的代码可以看出，ts2与ts1是两个独立的事

务，互不相干。Ts2是否成功并不依赖于 ts1。如果methodA方法在调用methodB方法后的

doSomeThingB方法失败了，而methodB方法所做的结果依然被提交。而除了 methodB之外的其它代

码导致的结果却被回滚了。使用PROPAGATION_REQUIRES_NEW,需要使用 JtaTransactionManager作

为事务管理器。

（

5）PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。使用

PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作为事务管理器。（代码示例

同上，可同理推出）

（

6）PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常。

（

7）PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事

务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。这是一个嵌套事务,使用JDBC 3.0

驱动时,仅仅支持DataSourceTransactionManager作为事务管理器。需要JDBC 驱动的

java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了同样的功能。使用

PROPAGATION_NESTED，还需要把PlatformTransactionManager的nestedTransactionAllowed属性

设为true;而 nestedTransactionAllowed属性值默认为false。

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_NESTED

methodB(){

……

}

如果单独调用methodB方法，则按REQUIRED属性执行。如果调用methodA方法，相当于下面的效果：

main(){

Connection con = null;

Savepoint savepoint = null;

try{

con = getConnection();当methodB方法调用之前，调用setSavepoint方法，保存当前的状态到savepoint。如果methodB方法

调用失败，则恢复到之前保存的状态。但是需要注意的是，这时的事务并没有进行提交，如果后续的代

码(doSomeThingB()方法)调用失败，则回滚包括methodB方法的所有操作。

嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的

动作。而内层事务操作失败并不会引起外层事务的回滚。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:它们非常类似,都像一个嵌套事

务，如果不存在一个活动的事务，都会开启一个新的事务。使用 PROPAGATION_REQUIRES_NEW时，

内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回

滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它需要JTA事务管理器的支持。

使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会

导致外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持

PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA

TrasactionManager实现可能有不同的支持方式。

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全

commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开

始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。

另一方面, PROPAGATION_NESTED 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务. 潜

套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套

事务是外部事务的一部分, 只有外部事务结束后它才会被提交。

由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于,

PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子

事务, 如果外部事务 commit, 嵌套事务也会被 commit, 这个规则同样适用于 roll back.

PROPAGATION_REQUIRED应该是我们首先的事务传播行为。它能够满足我们大多数的事务需求。

2.2.2 隔离级别

事务的第二个维度就是隔离级别（isolation level）。隔离级别定义了一个事务可能受其他并发事务影响

的程度。

（

1）并发事务引起的问题

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务。并发虽然是必须

的，但可能会导致一下的问题。

con.setAutoCommit(false);

doSomeThingA();

savepoint = con2.setSavepoint();

try{

methodB();

} catch(RuntimeException ex) {

con.rollback(savepoint);

} finally {

//释放资源

}

doSomeThingB();

con.commit();

} catch(RuntimeException ex) {

con.rollback();

} finally {

//释放资源

}

}脏读（Dirty reads）——脏读发生在一个事务读取了另一个事务改写但尚未提交的数据时。

如果改写在稍后被回滚了，那么第一个事务获取的数据就是无效的。

不可重复读（Nonrepeatable read）——不可重复读发生在一个事务执行相同的查询两次或

两次以上，但是每次都得到不同的数据时。这通常是因为另一个并发事务在两次查询期间进

行了更新。

幻读（Phantom read）——幻读与不可重复读类似。它发生在一个事务（T1）读取了几行

数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）

就会发现多了一些原本不存在的记录。

不可重复读与幻读的区别

不可重复读的重点是修改:

同样的条件, 你读取过的数据, 再次读取出来发现值不一样了

例如：在事务1中，Mary 读取了自己的工资为1000,操作并没有完成

con1 = getConnection();

select salary from employee empId ="Mary";

在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.

con2 = getConnection();

update employee set salary = 2000;

con2.commit();

在事务1中，Mary 再次读取自己的工资时，工资变为了2000

//con1

select salary from employee empId ="Mary";

在一个事务中前后两次读取的结果并不一致，导致了不可重复读。

幻读的重点在于新增或者删除：

同样的条件, 第1次和第2次读出来的记录数不一样

例如：目前工资为1000的员工有10人。事务1,读取所有工资为1000的员工。

con1 = getConnection();

Select * from employee where salary =1000;

共读取10条记录

这时另一个事务向employee表插入了一条员工记录，工资也为1000

con2 = getConnection();

Insert into employee(empId,salary) values("Lili",1000);

con2.commit();

事务1再次读取所有工资为1000的员工

//con1

select * from employee where salary =1000;

共读取到了11条记录，这就产生了幻像读。隔离级别

含义

ISOLATION_DEFAULT

使用后端数据库默认的隔离级别

ISOLATION_READ_UNCOMMITTED

最低的隔离级别，允许读取尚未提交的数据变更，可能会

导致脏读、幻读或不可重复读

ISOLATION_READ_COMMITTED

允许读取并发事务已经提交的数据，可以阻止脏读，但是

幻读或不可重复读仍有可能发生

ISOLATION_REPEATABLE_READ

对同一字段的多次读取结果都是一致的，除非数据是被本

身事务自己所修改，可以阻止脏读和不可重复读，但幻读

仍有可能发生

ISOLATION_SERIALIZABLE

最高的隔离级别，完全服从ACID的隔离级别，确保阻止脏

读、不可重复读以及幻读，也是最慢的事务隔离级别，因

为它通常是通过完全锁定事务相关的数据库表来实现的

从总的结果来看, 似乎不可重复读和幻读都表现为两次读取的结果不一致。但如果你从控制的角度来看,

两者的区别就比较大。

对于前者, 只需要锁住满足条件的记录。

对于后者, 要锁住满足条件及其相近的记录。

（

2）隔离级别

2.2.3 只读

事务的第三个特性是它是否为只读事务。如果事务只对后端的数据库进行该操作，数据库可以利用事务

的只读特性来进行一些特定的优化。通过将事务设置为只读，你就可以给数据库一个机会，让它应用它

认为合适的优化措施。

2.2.4 事务超时

为了使应用程序很好地运行，事务不能运行太长的时间。因为事务可能涉及对后端数据库的锁定，所以

长时间的事务会不必要的占用数据库资源。事务超时就是事务的一个定时器，在特定时间内事务如果没

有执行完毕，那么就会自动回滚，而不是一直等待其结束。

2.2.5 回滚规则

事务五边形的最后一个方面是一组规则，这些规则定义了哪些异常会导致事务回滚而哪些不会。默认情

况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行

为是一致的）

但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务

遇到特定的异常不回滚，即使这些异常是运行期异常。

2.3 事务状态

上面讲到的调用PlatformTransactionManager接口的getTransaction()的方法得到的是

TransactionStatus接口的一个实现，这个接口的内容如下：

public interface TransactionStatus{

boolean isNewTransaction(); // 是否是新的事物

boolean hasSavepoint(); // 是否有恢复点

void setRollbackOnly(); // 设置为只回滚

boolean isRollbackOnly(); // 是否为只回滚

boolean isCompleted; // 是否已完成

}可以发现这个接口描述的是一些处理事务提供简单的控制事务执行和查询事务状态的方法，在回滚或提

交的时候需要应用对应的事务状态。

3 编程式事务

3.1 编程式和声明式事务的区别

Spring提供了对编程式事务和声明式事务的支持，编程式事务允许用户在代码中精确定义事务的边界，

而声明式事务（基于AOP）有助于用户将操作与事务规则进行解耦。

简单地说，编程式事务侵入到了业务代码里面，但是提供了更加详细的事务管理；而声明式事务由于基

于AOP，所以既能起到事务管理的作用，又可以不影响业务代码的具体实现。

3.2 如何实现编程式事务？

Spring提供两种方式的编程式事务管理，分别是：使用TransactionTemplate和直接使用

PlatformTransactionManager。

3.2.1 使用TransactionTemplate

采用TransactionTemplate和采用其他Spring模板，如JdbcTempalte和HibernateTemplate是一样的方

法。它使用回调方法，把应用程序从处理取得和释放资源中解脱出来。如同其他模板，

TransactionTemplate是线程安全的。代码片段：

使用TransactionCallback()可以返回一个值。如果使用TransactionCallbackWithoutResult则没有返回

值。

3.2.2 使用PlatformTransactionManager

示例代码如下：

TransactionTemplate tt = new TransactionTemplate(); // 新建一个

TransactionTemplate

Object result = tt.execute(

new TransactionCallback(){

public Object doTransaction(TransactionStatus status){

updateOperation();

return resultOfUpdateOperation();

}

}); // 执行execute方法进行事务管理4 声明式事务

4.1 配置方式

*注：以下配置代码参考自Spring事务配置的五种方式

根据代理机制的不同，总结了五种Spring事务的配置方式，配置文件如下：

（

1）每个Bean都有一个代理

DataSourceTransactionManager dataSourceTransactionManager = new

DataSourceTransactionManager(); //定义一个某个框架平台的TransactionManager，如JDBC、

Hibernate

dataSourceTransactionManager.setDataSource(this.getJdbcTemplate().getDataSource(

)); // 设置数据源

DefaultTransactionDefinition transDef = new DefaultTransactionDefinition();

// 定义事务属性

transDef.setPropagationBehavior(DefaultTransactionDefinition.PROPAGATION_REQUIRE

D); // 设置传播行为属性

TransactionStatus status =

dataSourceTransactionManager.getTransaction(transDef); // 获得事务状态

try {

// 数据库操作

dataSourceTransactionManager.commit(status);// 提交

} catch (Exception e) {

dataSourceTransactionManager.rollback(status);// 回滚

}

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configurationClass"

value="org.hibernate.cfg.AnnotationConfiguration" />

</bean>

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

</bean>

<bean id="userDao"

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

<property name="proxyInterfaces"

value="com.bluesky.spring.dao.GeneratorDao" />

<props>

<prop key="*">PROPAGATION_REQUIRED</prop>

</props>

</property>

</bean>

</beans>

（

2）所有Bean共享一个代理基类

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configurationClass"

value="org.hibernate.cfg.AnnotationConfiguration" />

</bean>

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

<bean id="transactionBase"

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"

lazy-init="true" abstract="true">

<props><prop key="*">PROPAGATION_REQUIRED</prop>

</props>

</property>

</bean>

</bean>

</bean>

</beans>

（

3）使用拦截器

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configurationClass"

value="org.hibernate.cfg.AnnotationConfiguration" />

</bean>

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

<bean id="transactionInterceptor"

class="org.springframework.transaction.interceptor.TransactionInterceptor">

<props>

<prop key="*">PROPAGATION_REQUIRED</prop>

</props>

</property>

</bean>

<bean

class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">

</list>

</property>

<list>

<value>transactionInterceptor</value>

</list>

</property>

</bean>

</bean>

</beans>

（

4）使用tx标签配置的拦截器

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<context:annotation-config />

<context:component-scan base-package="com.bluesky" />

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configurationClass"

value="org.hibernate.cfg.AnnotationConfiguration" />

</bean>

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

<tx:advice id="txAdvice" transaction-manager="transactionManager">

<tx:attributes>

<tx:method name="*" propagation="REQUIRED" />

</tx:attributes>

</tx:advice>

<aop:config><aop:pointcut id="interceptorPointCuts"

expression="execution(* com.bluesky.spring.dao.*.*(..))" />

<aop:advisor advice-ref="txAdvice"

pointcut-ref="interceptorPointCuts" />

</aop:config>

</beans>

（

5）全注解

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<context:annotation-config />

<context:component-scan base-package="com.bluesky" />

<tx:annotation-driven transaction-manager="transactionManager"/>

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">

<property name="configurationClass"

value="org.hibernate.cfg.AnnotationConfiguration" />

</bean>

<bean id="transactionManager"

class="org.springframework.orm.hibernate3.HibernateTransactionManager">

</bean>

</beans>

此时在DAO上需加上@Transactional注解，如下：

package com.bluesky.spring.dao;

import java.util.List;

import org.hibernate.SessionFactory;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

import org.springframework.stereotype.Component;

import com.bluesky.spring.domain.User;4.2 一个声明式事务的实例

*注：该实例参考自Spring中的事务管理实例详解

首先是数据库表

book(isbn, book_name, price)

account(username, balance)

book_stock(isbn, stock)

然后是XML配置

使用的类

BookShopDao

@Transactional

@Component("userDao")

public class UserDaoImpl extends HibernateDaoSupport implements UserDao {

public List<User> listUsers() {

return this.getSession().createQuery("from User").list();

}

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:aop="http://www.springframework.org/schema/aop"

xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<context:component-scan

base-package="com.springinaction.transaction">

</context:component-scan>

<tx:annotation-driven transaction-manager="txManager"/>

<bean id="transactionManager"

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

</bean>

</beans>package com.springinaction.transaction;

public interface BookShopDao {

// 根据书号获取书的单价

public int findBookPriceByIsbn(String isbn);

// 更新书的库存，使书号对应的库存-1

public void updateBookStock(String isbn);

// 更新用户的账户余额：account的balance-price

public void updateUserAccount(String username, int price);

}

BookShopDaoImpl

package com.springinaction.transaction;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.jdbc.core.JdbcTemplate;

import org.springframework.stereotype.Repository;

@Repository("bookShopDao")

public class BookShopDaoImpl implements BookShopDao {

@Autowired

private JdbcTemplate JdbcTemplate;

@Override

public int findBookPriceByIsbn(String isbn) {

String sql = "SELECT price FROM book WHERE isbn = ?";

return JdbcTemplate.queryForObject(sql, Integer.class, isbn);

}

@Override

public void updateBookStock(String isbn) {

//检查书的库存是否足够，若不够，则抛出异常

String sql2 = "SELECT stock FROM book_stock WHERE isbn = ?";

int stock = JdbcTemplate.queryForObject(sql2, Integer.class, isbn);

if (stock == 0) {

throw new BookStockException("库存不足！");

}

String sql = "UPDATE book_stock SET stock = stock - 1 WHERE isbn = ?";

JdbcTemplate.update(sql, isbn);

}

@Override

public void updateUserAccount(String username, int price) {

//检查余额是否不足，若不足，则抛出异常

String sql2 = "SELECT balance FROM account WHERE username = ?";

int balance = JdbcTemplate.queryForObject(sql2, Integer.class,

username);

if (balance < price) {

throw new UserAccountException("余额不足！");

}

String sql = "UPDATE account SET balance = balance - ? WHERE username =

?";

JdbcTemplate.update(sql, price, username);}

}

BookShopService

package com.springinaction.transaction;

public interface BookShopService {

public void purchase(String username, String isbn);

}

BookShopServiceImpl

package com.springinaction.transaction;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;

import org.springframework.transaction.annotation.Isolation;

import org.springframework.transaction.annotation.Propagation;

import org.springframework.transaction.annotation.Transactional;

@Service("bookShopService")

public class BookShopServiceImpl implements BookShopService {

@Autowired

private BookShopDao bookShopDao;

/**

* 1.添加事务注解

* 使用propagation 指定事务的传播行为，即当前的事务方法被另外一个事务方法调用时如何使用事

务。

* 默认取值为REQUIRED，即使用调用方法的事务

* REQUIRES_NEW：使用自己的事务，调用的事务方法的事务被挂起。

* 2.使用isolation 指定事务的隔离级别，最常用的取值为READ_COMMITTED

* 3.默认情况下 Spring 的声明式事务对所有的运行时异常进行回滚，也可以通过对应的属性进行设

置。通常情况下，默认值即可。

* 4.使用readOnly 指定事务是否为只读。表示这个事务只读取数据但不更新数据，这样可以帮助数

据库引擎优化事务。若真的是一个只读取数据库值得方法，应设置readOnly=true

* 5.使用timeOut 指定强制回滚之前事务可以占用的时间。

@Transactional(propagation=Propagation.REQUIRES_NEW,

isolation=Isolation.READ_COMMITTED,

noRollbackFor={UserAccountException.class},

readOnly=true, timeout=3)

@Override

public void purchase(String username, String isbn) {

//1.获取书的单价

int price = bookShopDao.findBookPriceByIsbn(isbn);

//2.更新书的库存

bookShopDao.updateBookStock(isbn);

//3.更新用户余额

bookShopDao.updateUserAccount(username, price);

}

}Cashier

package com.springinaction.transaction;

import java.util.List;

public interface Cashier {

public void checkout(String username, List<String>isbns);

}

CashierImpl：CashierImpl.checkout和bookShopService.purchase联合测试了事务的传播行为

package com.springinaction.transaction;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;

import org.springframework.transaction.annotation.Transactional;

@Service("cashier")

public class CashierImpl implements Cashier {

@Autowired

private BookShopService bookShopService;

@Transactional

@Override

public void checkout(String username, List<String> isbns) {

for(String isbn : isbns) {

bookShopService.purchase(username, isbn);

}

BookStockException

package com.springinaction.transaction;

public class BookStockException extends RuntimeException {

private static final long serialVersionUID = 1L;

public BookStockException() {

super();

// TODO Auto-generated constructor stub

}

public BookStockException(String arg0, Throwable arg1, boolean arg2,

boolean arg3) {

super(arg0, arg1, arg2, arg3);

// TODO Auto-generated constructor stub

}

public BookStockException(String arg0, Throwable arg1) {

super(arg0, arg1);

// TODO Auto-generated constructor stub

}

public BookStockException(String arg0) {super(arg0);

// TODO Auto-generated constructor stub

}

public BookStockException(Throwable arg0) {

super(arg0);

// TODO Auto-generated constructor stub

}

UserAccountException

package com.springinaction.transaction;

public class UserAccountException extends RuntimeException {

private static final long serialVersionUID = 1L;

public UserAccountException() {

super();

// TODO Auto-generated constructor stub

}

public UserAccountException(String arg0, Throwable arg1, boolean arg2,

boolean arg3) {

super(arg0, arg1, arg2, arg3);

// TODO Auto-generated constructor stub

}

public UserAccountException(String arg0, Throwable arg1) {

super(arg0, arg1);

// TODO Auto-generated constructor stub

}

public UserAccountException(String arg0) {

super(arg0);

// TODO Auto-generated constructor stub

}

public UserAccountException(Throwable arg0) {

super(arg0);

// TODO Auto-generated constructor stub

}

测试类

package com.springinaction.transaction;

import java.util.Arrays;

import org.junit.Test;

import org.springframework.context.ApplicationContext;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SpringTransitionTest {SpringMVC概述

什么是Spring MVC？简单介绍下你对Spring MVC的理解？

Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级 Web框架，通过把模型-视

图-控制器分离，将web层进行职责解耦，把复杂的 web应用分成逻辑清晰的几部分，简化开发，减少出

错，方便组内开发人员之间的配合。

Spring MVC的优点

（

1）可以支持各种视图技术,而不仅仅局限于JSP；

（

2）与Spring框架集成（如IoC容器、AOP等）；

（

3）清晰的角色分配：前端控制器(dispatcherServlet) , 请求到处理器映射（handlerMapping), 处理

器适配器（HandlerAdapter), 视图解析器（ViewResolver）。

private ApplicationContext ctx = null;

private BookShopDao bookShopDao = null;

private BookShopService bookShopService = null;

private Cashier cashier = null;

{

ctx = new ClassPathXmlApplicationContext("config/transaction.xml");

bookShopDao = ctx.getBean(BookShopDao.class);

bookShopService = ctx.getBean(BookShopService.class);

cashier = ctx.getBean(Cashier.class);

}

@Test

public void testBookShopDaoFindPriceByIsbn() {

System.out.println(bookShopDao.findBookPriceByIsbn("1001"));

}

@Test

public void testBookShopDaoUpdateBookStock(){

bookShopDao.updateBookStock("1001");

}

@Test

public void testBookShopDaoUpdateUserAccount(){

bookShopDao.updateUserAccount("AA", 100);

}

@Test

public void testBookShopService(){

bookShopService.purchase("AA", "1001");

}

@Test

public void testTransactionPropagation(){

cashier.checkout("AA", Arrays.asList("1001", "1002"));

}

}（

4）支持各种请求资源的映射策略。 ### 核心组件

Spring MVC的主要组件？

（

1）前端控制器 DispatcherServlet（不需要程序员开发）

作用：接收请求、响应结果，相当于转发器，有了DispatcherServlet 就减少了其它组件之间的耦合

度。

（

2）处理器映射器HandlerMapping（不需要程序员开发）

作用：根据请求的URL来查找Handler

（

3）处理器适配器HandlerAdapter

注意：在编写Handler的时候要按照HandlerAdapter要求的规则去编写，这样适配器HandlerAdapter

才可以正确的去执行Handler。

（

4）处理器Handler（需要程序员开发）

（

5）视图解析器 ViewResolver（不需要程序员开发）

作用：进行视图的解析，根据视图逻辑名解析成真正的视图（view）

（

6）视图View（需要程序员开发jsp）

View是一个接口，它的实现类支持不同的视图类型（jsp，freemarker，pdf等等）

什么是DispatcherServlet

Spring的MVC框架是围绕DispatcherServlet来设计的，它用来处理所有的 HTTP请求和响应。

什么是Spring MVC框架的控制器？

控制器提供一个访问应用程序的行为，此行为通常通过服务接口实现。控制器解析用户输入并将其转换

为一个由视图呈现给用户的模型。Spring用一个非常抽象的方式实现了一个控制层，允许用户创建多种

用途的控制器。

Spring MVC的控制器是不是单例模式,如果是,有什么问题,怎么解决？

答：是单例模式,所以在多线程访问的时候有线程安全问题,不要用同步,会影响性能的,解决方案是在控制

器里面不能写字段。

工作原理

请描述Spring MVC的工作流程？描述一下 DispatcherServlet 的工作流程？

（

1）用户发送请求至前端控制器DispatcherServlet；

（

2） DispatcherServlet收到请求后，调用HandlerMapping处理器映射器，请求获取Handle；

（

3）处理器映射器根据请求url找到具体的处理器，生成处理器对象及处理器拦截器(如果有则生成)一

并返回给DispatcherServlet；

（

4）DispatcherServlet 调用 HandlerAdapter处理器适配器；

（

5）HandlerAdapter 经过适配调用具体处理器(Handler，也叫后端控制器)；

（

6）Handler执行完成返回ModelAndView；

（

7）HandlerAdapter将Handler执行结果ModelAndView返回给 DispatcherServlet；

（

8）DispatcherServlet将ModelAndView传给ViewResolver视图解析器进行解析；

（

9）ViewResolver解析后返回具体View；

（10）DispatcherServlet对View进行渲染视图（即将模型数据填充至视图中）（11）DispatcherServlet响应用户。

MVC框架

MVC是什么？MVC设计模式的好处有哪些

mvc是一种设计模式（设计模式就是日常开发中编写代码的一种好的方法和经验的总结）。模型

（model）-视图（view）-控制器（controller），三层架构的设计模式。用于实现前端页面的展现与后

端业务数据处理的分离。

mvc设计模式的好处

1.分层设计，实现了业务系统各个组件之间的解耦，有利于业务系统的可扩展性，可维护性。

2.有利于系统的并行开发，提升开发效率。

常用注解

注解原理是什么

注解本质是一个继承了Annotation的特殊接口，其具体实现类是Java运行时生成的动态代理类。我们通

过反射获取注解时，返回的是Java运行时生成的动态代理对象。通过代理对象调用自定义注解的方法，

会终调用 AnnotationInvocationHandler的invoke方法。该方法会从memberValues这个Map中索引出

对应的值。而memberValues的来源是Java常量池。

Spring MVC常用的注解有哪些？

@RequestMapping：用于处理请求 url 映射的注解，可用于类或方法上。用于类上，则表示类中的所

有响应请求的方法都是以该地址作为父路径。

@RequestBody：注解实现接收http请求的json数据，将json转换为java对象。

@ResponseBody：注解实现将conreoller方法返回对象转化为json对象响应给客户。

SpingMvc中的控制器的注解一般用哪个,有没有别的注解可以替代？

答：一般用@Controller注解,也可以使用@RestController,@RestController 注解相当于

@ResponseBody ＋ @Controller,表示是表现层,除此之外，一般不用别的注解代替。

@Controller注解的作用

在Spring MVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据

经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在

Spring MVC 中提供了一个非常简

便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用@RequestMapping 和 @RequestParam 等一些注

解用以定义URL 请求和Controller 方法之间的映射，这样的Controller 就能被外界访问到。此外

Controller 不会直接依赖于

HttpServletRequest 和HttpServletResponse 等HttpServlet 对象，它们可以通过Controller 的方法参

数灵活的获取到。

@Controller 用于标记在一个类上，使用它标记的类就是一个Spring MVC

Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方

法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用

@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还

不能真正意义上的说它就是Spring MVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如

何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式：

在Spring MVC 的配置文件中定义MyController 的bean 对象。

在Spring MVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。

@RequestMapping注解的作用

RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。

用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。

RequestMapping注解有六个属性，下面我们把她分成三类进行说明（下面有相应示例）。

value， method

value：指定请求的实际地址，指定的地址可以是URI Template 模式（后面将会说明）；

method：指定请求的method类型， GET、POST、PUT、DELETE等； consumes，produces

consumes：指定处理请求的提交内容类型（Content-Type），例如 application/json, text/html;

produces: 指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回；

params，headers

params：指定request中必须包含某些参数值是，才让该方法处理。

headers：指定request中必须包含某些指定的header值，才能让该方法处理请求。

@ResponseBody注解的作用

作用：该注解用于将Controller的方法返回的对象，通过适当的

HttpMessageConverter转换为指定格式后，写入到Response对象的body数据区。

使用时机：返回的数据不是html标签的页面，而是其他某种格式的数据时（如json、xml等）使用；

@PathVariable和@RequestParam的区别

请求路径上有个id的变量值，可以通过@PathVariable来获取

@RequestMapping(value = “/page/{id}”, method =

RequestMethod.GET)

@RequestParam用来获得静态的URL请求入参 spring注解时action里用到。其他

Spring MVC与Struts2区别

相同点都是基于mvc的表现层框架，都用于web项目的开发。

不同点

1.前端控制器不一样。Spring MVC的前端控制器是servlet：

DispatcherServlet。struts2的前端控制器是filter：

StrutsPreparedAndExcutorFilter。

2.请求参数的接收方式不一样。Spring MVC是使用方法的形参接收请求的参数，基于方法的开发，线程

安全，可以设计为单例或者多例的开发，推荐使用单例模式的开发（执行效率更高），默认就是单例开

发模式。struts2是通过类的成员变量接收请求的参数，是基于类的开发，线程不安全，只能设计为多例

的开发。

3.Struts采用值栈存储请求和响应的数据，通过OGNL存取数据，Spring MVC 通过参数解析器是将

request请求内容解析，并给方法形参赋值，将数据和视图封装成ModelAndView对象，后又将

ModelAndView中的模型数据通过 reques域传输到页面。Jsp视图解析器默认使用jstl。

4.与spring整合不一样。Spring MVC是spring框架的一部分，不需要整合。在企业项目中，Spring MVC

使用更多一些。

Spring MVC怎么样设定重定向和转发的？

（

1）转发：在返回值前面加"forward:"，譬如"forward:user.do?name=method4"

（

2）重定向：在返回值前面加"redirect:"，譬如"redirect:http://www.baidu.com"

Spring MVC怎么和AJAX相互调用的？

通过Jackson框架就可以把Java里面的对象直接转化成Js可以识别的Json对象。

具体步骤如下：

（

1）加入Jackson.jar

（

2）在配置文件中配置json的映射

（

3）在接受Ajax方法里面可以直接返回Object,List等,但方法前面要加上@ResponseBody注解。

如何解决POST请求中文乱码问题，GET的又如何处理呢？

（

1）解决post请求乱码问题：

在web.xml中配置一个CharacterEncodingFilter过滤器，设置成utf-8；

1 <filter>

2 <filter-name>CharacterEncodingFilter</filter-name>

3 <filter-class>org.springframework.web.filter.CharacterEncodingFilter</fi

lter-class>

5 <init-param>

6 <param-name>encoding</param-name>

7 <param-value>utf-8</param-value>

8 </init-param>

9 </filter>

10（

2）get请求中文参数出现乱码解决方法有两个：

①修改tomcat配置文件添加编码与工程编码一致，如下：

②另外一种方法对参数进行重新编码：

String userName = new

String(request.getParamter(“userName”).getBytes(“ISO8859-

1”),“utf-8”)

ISO8859-1是tomcat默认编码，需要将tomcat编码后的内容按utf-8编码。

Spring MVC的异常处理？

答：可以将异常抛给Spring框架，由Spring框架来处理；我们只需要配置简单的异常处理器，在异常处

理器中添视图页面即可。

如果在拦截请求中，我想拦截get方式提交的方法,怎么配置

答：可以在@RequestMapping注解里面加上 method=RequestMethod.GET。

怎样在方法里面得到Request,或者Session？

答：直接在方法的形参中声明request,Spring MVC就自动把request对象传入。

如果想在拦截的方法里面得到从前台传入的参数,怎么得到？

答：直接在形参里面声明这个参数就可以,但必须名字和传过来的参数一样。

如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象？

答：直接在方法中声明这个对象,Spring MVC就自动会把属性赋值到这个对象里面。

Spring MVC中函数的返回值是什么？

答：返回值可以有很多类型,有String, ModelAndView。ModelAndView类把视图和数据都合并的一起

的，但一般用String比较好。

Spring MVC用什么对象从后台向前台传递数据的？

答：通过ModelMap对象,可以在这个对象里面调用put方法,把对象加到里面,前台就可以通过el表达式拿

到。

怎么样把ModelMap里面的数据放入Session里面？

答：可以在类上面加上@SessionAttributes注解,里面包含的字符串就是要放入session里面的key。

11 <filter-mapping>

12 <filter-name>CharacterEncodingFilter</filter-name>

13 <url-pattern>/*</url-pattern>

14 </filter-mapping>

1 <ConnectorURIEncoding="utf-8" connectionTimeout="20000" port="8080" proto

col="HTTP/1.1" redirectPort="8443"/>Spring MVC里面拦截器是怎么写的

有两种写法,一种是实现HandlerInterceptor接口，另外一种是继承适配器类，接着在接口方法当中，实

现处理逻辑；然后在Spring MVC的配置文件中配置拦截器即可：

介绍一下 WebApplicationContext

WebApplicationContext 继承了ApplicationContext 并增加了一些WEB应用必备的特有功能，它不同于

一般的ApplicationContext ，因为它能处理主题，并找到被关联的servlet。

Spring概述

1. 什么是spring?

Spring是一个轻量级Java开发框架，最早由Rod Johnson创建，目的是为了解决企业级应用开发的业务

逻辑层和其他各层的耦合问题。它是一个分层的 JavaSE/JavaEE full-stack（一站式）轻量级开源框架，

为开发Java应用程序提供全面的基础架构支持。Spring负责基础架构，因此Java开发者可以专注于应用

程序的开发。 Spring最根本的使命是解决企业级应用开发的复杂性，即简化Java开发。

Spring可以做很多事情，它为企业级开发提供给了丰富的功能，但是这些功能的底层都依赖于它的两个

核心特性，也就是依赖注入（dependency injection，DI）和面向切面编程（aspect-oriented

programming， AOP）。

为了降低Java开发的复杂性，Spring采取了以下4种关键策略

基于POJO的轻量级和最小侵入性编程；

通过依赖注入和面向接口实现松耦合；

基于切面和惯例进行声明式编程；

通过切面和模板减少样板式代码。

2. Spring框架的设计目标，设计理念，和核心是什么

Spring设计目标：Spring为开发者提供一个一站式轻量级应用开发平台；

Spring设计理念：在JavaEE开发中，支持POJO和JavaBean开发方式，使应用面向接口开发，充分支持

OO（面向对象）设计方法；Spring通过IoC容器实现对象耦合关系的管理，并实现依赖反转，将对象之

间的依赖关系交给IoC容器，实现解耦；

Spring框架的核心：IoC容器和AOP模块。通过IoC容器管理POJO对象以及他们之间的耦合关系；通过

AOP以动态非侵入的方式增强服务。 IoC让相互协作的组件保持松散的耦合，而AOP编程允许你把遍布

于应用各层的功能分离出来形成可重用的功能组件。

1

2 <mvc:interceptors>

3

4 <bean id="myInterceptor" class="com.zwp.action.MyHandlerInterceptor"></b

ean>

5

6 <mvc:interceptor>

7 <mvc:mapping path="/modelMap.do" />

8 <bean class="com.zwp.action.MyHandlerInterceptorAdapter" />

9 </mvc:interceptor>

10 </mvc:interceptors>3. Spring的优缺点是什么？

优点

方便解耦，简化开发

Spring就是一个大工厂，可以将所有对象的创建和依赖关系的维护，交给 Spring管理。

AOP编程的支持

Spring提供面向切面编程，可以方便的实现对程序进行权限拦截、运行监控等功能。

声明式事务的支持

只需要通过配置就可以完成对事务的管理，而无需手动编程。

方便程序的测试

Spring对Junit4支持，可以通过注解方便的测试Spring程序。

方便集成各种优秀框架

Spring不排斥各种优秀的开源框架，其内部提供了对各种优秀框架的直接支持（如：Struts、

Hibernate、MyBatis等）。

降低JavaEE API的使用难度

Spring对JavaEE开发中非常难用的一些API（JDBC、JavaMail、远程调用等），都提供了封装，使

这些API应用难度大大降低。

缺点

Spring明明一个很轻量级的框架，却给人感觉大而全

Spring依赖反射，反射影响性能

使用门槛升高，入门Spring需要较长时间

4. Spring有哪些应用场景

应用场景：JavaEE企业应用开发，包括SSH、SSM等

Spring价值：

Spring是非侵入式的框架，目标是使应用程序代码对框架依赖最小化；

Spring提供一个一致的编程模型，使应用直接使用POJO开发，与运行环境隔离开来；

Spring推动应用设计风格向面向对象和面向接口开发转变，提高了代码的重用性和可测试性；

5. Spring由哪些模块组成？

Spring 总共大约有 20 个模块，由 1300 多个不同的文件构成。而这些组件被分别整合在核心容器

（Core Container）、 AOP（Aspect Oriented Programming）和设备支持（Instrmentation）

、数据访问与集成（Data Access/Integeration）、 Web、消息（Messaging）、 Test等 6 个模

块中。以下是 Spring 5 的模块结构图：spring core：提供了框架的基本组成部分，包括控制反转（Inversion of Control，IOC）和依赖

注入（Dependency Injection，DI）功能。

spring beans：提供了BeanFactory，是工厂模式的一个经典实现，Spring将管理对象称为

Bean。

spring context：构建于 core 封装包基础上的 context 封装包，提供了一种框架式的对象访问方

法。

spring jdbc：提供了一个JDBC的抽象层，消除了烦琐的JDBC编码和数据库厂商特有的错误代码解

析，用于简化JDBC。

spring aop：提供了面向切面的编程实现，让你可以自定义拦截器、切点等。

spring Web：提供了针对 Web 开发的集成特性，例如文件上传，利用 servlet listeners 进行 ioc

容器初始化和针对 Web 的 ApplicationContext。

spring test：主要为测试提供支持的，支持使用JUnit或TestNG对Spring组件进行单元测试和集成

测试。

6. Spring 框架中都用到了哪些设计模式？

1. 工厂模式：BeanFactory就是简单工厂模式的体现，用来创建对象的实例；

2. 单例模式：Bean默认为单例模式。

3. 代理模式：Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术；

4. 模板方法：用来解决代码重复的问题。比如. RestTemplate, JmsTemplate, JpaTemplate。

5. 观察者模式：定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的

对象都会得到通知被制动更新，如Spring中 listener的实现–ApplicationListener。

7. 详细讲解一下核心容器（spring context应用上下文) 模块

这是基本的Spring模块，提供spring 框架的基础功能，BeanFactory 是任何以 spring为基础的应用的

核心。Spring 框架建立在此模块之上，它使Spring成为一个容器。

Bean 工厂是工厂模式的一个实现，提供了控制反转功能，用来把应用的配置和依赖从真正的应用代码

中分离。最常用的就是 org.springframework.beans.factory.xml.XmlBeanFactory ，它根据XML文件

中的定义加载beans。该容器从XML 文件读取配置元数据并用它去创建一个完全配置的系统或应用。8. Spring框架中有哪些不同类型的事件

Spring 提供了以下5种标准的事件：

1. 上下文更新事件（ContextRefreshedEvent）：在调用 ConfigurableApplicationContext 接口中

的refresh()方法时被触发。

2. 上下文开始事件（ContextStartedEvent）：当容器调用 ConfigurableApplicationContext的

Start()方法开始/重新开始容器时触发该事件。

3. 上下文停止事件（ContextStoppedEvent）：当容器调用 ConfigurableApplicationContext的

Stop()方法停止容器时触发该事件。

4. 上下文关闭事件（ContextClosedEvent）：当ApplicationContext被关闭时触发该事件。容器被

关闭时，其管理的所有单例Bean都被销毁。

5. 请求处理事件（RequestHandledEvent）：在Web应用中，当一个 http请求（request）结束触发

该事件。如果一个bean实现了 ApplicationListener接口，当一个ApplicationEvent 被发布以后，

bean 会自动被通知。

9. Spring 应用程序有哪些不同组件？

Spring 应用一般有以下组件：

接口 - 定义功能。

Bean 类 - 它包含属性，setter 和 getter 方法，函数等。

Bean 配置文件 - 包含类的信息以及如何配置它们。

Spring 面向切面编程（AOP） - 提供面向切面编程的功能。

用户程序 - 它使用接口。

10. 使用 Spring 有哪些方式？

使用 Spring 有以下方式：

作为一个成熟的 Spring Web 应用程序。

作为第三方 Web 框架，使用 Spring Frameworks 中间层。

作为企业级 Java Bean，它可以包装现有的 POJO（Plain Old Java Objects）。

用于远程使用。

Spring控制反转(IOC)

什么是Spring IOC 容器？

控制反转即IoC (Inversion of Control)，它把传统上由程序代码直接操控的对

象的调用权交给容器，通过容器来实现对象组件的装配和管理。所谓的“控制反

转”概念就是对组件对象控制权的转移，从程序代码本身转移到了外部容器。

Spring IOC 负责创建对象，管理对象（通过依赖注入（DI），装配对象，配置对象，并且管理这些对象

的整个生命周期。

控制反转(IoC)有什么作用

管理对象的创建和依赖关系的维护。对象的创建并不是一件简单的事，在对象关系比较复杂时，如

果依赖关系需要程序猿来维护的话，那是相当头疼的

解耦，由容器去维护具体的对象

托管了类的产生过程，比如我们需要在类的产生过程中做一些处理，最直接的例子就是代理，如果

有容器程序可以把这部分处理交给容器，应用程序则无需去关心类是如何完成代理的IOC的优点是什么？

IOC 或依赖注入把应用的代码量降到最低。

它使应用容易测试，单元测试不再需要单例和JNDI查找机制。

最小的代价和最小的侵入性使松散耦合得以实现。

IOC容器支持加载服务时的饿汉式初始化和懒加载。

Spring IoC 的实现机制

Spring 中的 IoC 的实现原理就是工厂模式加反射机制。

示例：

Spring 的 IoC支持哪些功能

Spring 的 IoC 设计支持以下功能：依赖注入依赖检查自动装配支持集合指定初始化方法和销毁方法

支持回调某些方法（但是需要实现 Spring 接口，略有侵入）

其中，最重要的就是依赖注入，从 XML 的配置上说，即 ref 标签。对应 Spring

1 interface Fruit {

2 public abstract void eat();

3 }

5 class Apple implements Fruit {

6 public void eat(){

7 System.out.println("Apple");

8 }

9 }

11 class Orange implements Fruit {

12 public void eat(){

13 System.out.println("Orange");

14 }

15 }

17 class Factory {

18 public static Fruit getInstance(String ClassName) {

19 Fruit f=null;

20 try {

21 f=(Fruit)Class.forName(ClassName).newInstance();

22 } catch (Exception e) {

23 e.printStackTrace();

24 }

25 return f;

26 }

27 }

29 class Client {

30 public static void main(String[] a) {

31 Fruit f=Factory.getInstance("io.github.dunwu.spring.Apple");

32 if(f!=null){

33 f.eat();

34 }

35 }

36 }RuntimeBeanReference 对象。

对于 IoC 来说，最重要的就是容器。容器管理着 Bean 的生命周期，控制着 Bean 的依赖注入。

BeanFactory 和 ApplicationContext有什么区别？

BeanFactory和ApplicationContext是Spring的两大核心接口，都可以当做 Spring的容器。其中

ApplicationContext是BeanFactory的子接口。

依赖关系

BeanFactory：是Spring里面最底层的接口，包含了各种Bean的定义，读取 bean配置文档，管理bean

的加载、实例化，控制bean的生命周期，维护bean 之间的依赖关系。

ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具

有的功能外，还提供了更完整的框架功能：

继承MessageSource，因此支持国际化。统一的资源文件访问方式。

提供在监听器中注册bean的事件。

同时加载多个配置文件。

载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的web

层。

加载方式

BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean 时(调用getBean())，才

对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个

属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。

ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可

以发现Spring中存在的配置错误，这样有利于检查所

依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确

保当你需要的时候，你就不用等待，因为它们已经创建好了。

相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较

多时，程序启动较慢。

创建方式

BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用

ContextLoader。

注册方式

BeanFactory和ApplicationContext都支持BeanPostProcessor、

BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而

ApplicationContext则是自动注册。

Spring 如何设计容器的，BeanFactory和 ApplicationContext的

关系详解

Spring 作者 Rod Johnson 设计了两个接口用以表示容器。

BeanFactory

ApplicationContext

BeanFactory 简单粗暴，可以理解为就是个 HashMap，Key 是 BeanName，Value 是 Bean 实例。通常只提供注册（put），获取（get）这两个功能。我们可以称之为 “低级容

器”。

ApplicationContext 可以称之为 “高级容器”。因为他比 BeanFactory 多了更多的功能。他继承了多个接

口。因此具备了更多的功能。例如资源的获取，支持多种消息（例如 JSP tag 的支持），对

BeanFactory 多了工具级别的支持等待。所以你看他的名字，已经不是 BeanFactory 之类的工厂了，而

是 “应用上下文”，代表着整个大容器的所有功能。该接口定义了一个 refresh 方法，此方法是所有阅读

Spring 源码的人的最熟悉的方法，用于刷新整个容器，即重新加载/刷新所有的 bean。

当然，除了这两个大接口，还有其他的辅助接口，这里就不介绍他们了。

BeanFactory和ApplicationContext的关系

为了更直观的展示 “低级容器” 和 “高级容器” 的关系，这里通过常用的

ClassPathXmlApplicationContext 类来展示整个容器的层级 UML 关系。

有点复杂？先不要慌，我来解释一下。

最上面的是 BeanFactory，下面的 3 个绿色的，都是功能扩展接口，这里就不展开讲。

看下面的隶属 ApplicationContext 粉红色的 “高级容器”，依赖着 “低级容器”，这里说的是依赖，不是继

承哦。他依赖着 “低级容器” 的 getBean 功

能。而高级容器有更多的功能：支持不同的信息源头，可以访问文件资源，支持应用事件（Observer 模

式）。

通常用户看到的就是 “高级容器”。但 BeanFactory 也非常够用啦！左边灰色区域的是 “低级容器”，只

负载加载 Bean，获取 Bean。容器其他的高级功能是没有的。例如上图画的 refresh 刷新 Bean 工厂所

有配置，生命周期事件回调等。

小结

说了这么多，不知道你有没有理解Spring IoC？这里小结一下：IoC 在 Spring 里，只需要低级容器就可

以实现，2 个步骤：

1. 加载配置文件，解析成 BeanDefinition 放在 Map 里。

2. 调用 getBean 的时候，从 BeanDefinition 所属的 Map 里，拿出

Class 对象进行实例化，同时，如果有依赖关系，将递归调用 getBean 方法 —— 完成依赖注入。上面就是 Spring 低级容器（BeanFactory）的 IoC。

至于高级容器 ApplicationContext，他包含了低级容器的功能，当他执行 refresh 模板方法的时候，将

刷新整个容器的 Bean。同时其作为高级容器，包含了太多的功能。一句话，他不仅仅是 IoC。他支持不

同信息源头，支持

BeanFactory 工具类，支持层级容器，支持访问文件资源，支持事件发布通知，支持接口回调等等。

ApplicationContext通常的实现是什么？

FileSystemXmlApplicationContext ：此容器从一个XML文件中加载beans 的定义，XML Bean 配置文

件的全路径名必须提供给它的构造函数。

ClassPathXmlApplicationContext：此容器也从一个XML文件中加载beans 的定义，这里，你需要正确

设置classpath因为这个容器将在classpath里找 bean配置。

WebXmlApplicationContext：此容器加载一个XML文件，此文件定义了一个WEB应用的所有bean。

什么是Spring的依赖注入？

控制反转IoC是一个很大的概念，可以用不同的方式来实现。其主要实现方式有两种：依赖注入和依赖查

找依赖注入：相对于IoC而言，依赖注入(DI)更加准确地描述了IoC的设计理念。所谓依赖注入

（Dependency Injection），即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动

态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。组件不做定位查询，只

提供普通的Java方法让容器去决定依赖关系。

依赖注入的基本原则

依赖注入的基本原则是：应用组件不应该负责查找资源或者其他依赖的协作对象。配置对象的工作应该

由IoC容器负责，“查找资源”的逻辑应该从应用组件的代码中抽取出来，交给IoC容器负责。容器全权负

责组件的装配，它会把符合依赖关系的对象通过属性（JavaBean中的setter）或者是构造器传递给需要

的对象。

依赖注入有什么优势

依赖注入之所以更流行是因为它是一种更可取的方式：让容器全权负责依赖查询，受管组件只需要暴露

JavaBean的setter方法或者带参数的构造器或者接

口，使容器可以在初始化时组装对象的依赖关系。其与依赖查找方式相比，主要优势为：

查找定位操作与应用代码完全无关。

不依赖于容器的API，可以很容易地在任何容器以外使用应用对象。

不需要特殊的接口，绝大多数对象可以做到完全不必依赖容器。

有哪些不同类型的依赖注入实现方式？

依赖注入是时下最流行的IoC实现方式，依赖注入分为接口注入（Interface Injection），Setter方法注

入（Setter Injection）和构造器注入（Constructor

Injection）三种方式。其中接口注入由于在灵活性和易用性比较差，现在从Spring4开始已被废弃。

构造器依赖注入：构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参

数代表一个对其他类的依赖。

Setter方法注入：Setter方法注入是容器通过调用无参构造器或无参static工厂方法实例化bean之后，

调用该bean的setter方法，即实现了基于setter的依赖注入。构造函数注入

setter注入

没有部分注入

有部分注入

不会覆盖 setter 属性

会覆盖 setter 属性

任意修改都会创建一个新实例

任意修改不会创建一个新实例

适用于设置很多属性

适用于设置少量属性

构造器依赖注入和 Setter方法注入的区别

两种依赖方式都可以使用，构造器注入和Setter方法注入。最好的解决方案是用构造器参数实现强制依

赖，setter方法实现可选依赖。

Spring Beans（19）什么是Spring beans？

Spring beans 是那些形成Spring应用的主干的java对象。它们被Spring IOC容器初始化，装配，和管

理。这些beans通过容器中配置的元数据创建。比如，以XML文件中的形式定义。

一个 Spring Bean 定义包含什么？

一个Spring Bean 的定义包含容器必知的所有配置元数据，包括bean，它的生命周期详情及它的依赖。

如何创建一个如何给Spring 容器提供配置元数据？Spring有几种配置方式

这里有三种重要的方法给Spring 容器提供配置元数据。

XML配置文件。

基于注解的配置。

基于java的配置。

Spring配置文件包含了哪些信息

Spring配置文件是个XML 文件，这个文件包含了类信息，描述了如何配置它们，以及如何相互调用。

Spring基于xml注入bean的几种方式

1. Set方法注入；

2. 构造器注入：①通过index设置参数的位置；②通过type设置参数类型；

3. 静态工厂注入；

4. 实例工厂；

你怎样定义类的作用域？

当定义一个在Spring里，我们还能给这个bean声明一个作用域。它可以通过 bean 定义中的scope属性

来定义。如，当Spring要在需要的时候每次生产一个新的bean实例，bean的scope属性被指定为

prototype。另一方面，一个bean 每次使用的时候必须返回同一个实例，这个bean的scope 属性必须

设为 singleton。

解释Spring支持的几种bean的作用域

Spring框架支持以下五种bean的作用域：

singleton : bean在每个Spring ioc 容器中只有一个实例。

prototype：一个bean的定义可以有多个实例。request：每次http请求都会创建一个bean，该作用域仅在基于web的SpringApplicationContext

情形下有效。

session：在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring

ApplicationContext情形下有效。

global-session：在一个全局的HTTP Session中，一个bean定义对应一个

实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

注意：缺省的Spring bean 的作用域是Singleton。使用 prototype 作用域需要慎重的思考，因为频繁创

建和销毁 bean 会带来很大的性能开销。

Spring框架中的单例bean是线程安全的吗？

不是，Spring框架中的单例bean不是线程安全的。

spring 中的 bean 默认是单例模式，spring 框架并没有对单例 bean 进行多线程的封装处理。

实际上大部分时候 spring bean 无状态的（比如 dao 类），所有某种程度上来说 bean 也是安全的，但

如果 bean 有状态的话（比如 view model 对象），那就要开发者自己去保证线程安全了，最简单的就

是改变 bean 的作用域，

把“singleton”变更为“prototype”，这样请求 bean 相当于 new Bean() 了，所以就可以保证线程安全

了。

有状态就是有数据存储功能。

无状态就是不会保存数据。

Spring如何处理线程并发问题？

在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声

明为singleton作用域，因为Spring对一些Bean中非线程安全状态采用ThreadLocal进行处理，解决线程

安全问题。

ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。同步机制采用了“时间换

空间”的方式，仅提供一份变量，不同的线程在访问前

需要获取锁，没获得锁的线程则需要排队。而ThreadLocal采用了“空间换时间”的方式。

ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为

每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程

安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。解释Spring框架中

bean的生命周期

在传统的Java应用中，bean的生命周期很简单。使用Java关键字new进行bean 实例化，然后该bean就

可以使用了。一旦该bean不再被使用，则由Java自动进行垃圾回收。相比之下，Spring容器中的bean的

生命周期就显得相对复杂多了。正确理解Spring bean的生命周期非常重要，因为你或许要利用Spring提

供的扩展点来自定义bean的创建过程。下图展示了bean装载到Spring应用上下文中的一个典型的生命

周期过程。bean在Spring容器中从创建到销毁经历了若干阶段，每一阶段都可以针对 Spring如何管理bean进行个

性化定制。

正如你所见，在bean准备就绪之前，bean工厂执行了若干启动步骤。

我们对上图进行详细描述：

Spring对bean进行实例化；

Spring将值和bean的引用注入到bean对应的属性中；

如果bean实现了BeanNameAware接口，Spring将bean的ID传递给setBeanName()方法；

如果bean实现了BeanFactoryAware接口，Spring将调用setBeanFactory()方

法，将BeanFactory容器实例传入；

如果bean实现了ApplicationContextAware接口，Spring将调用 setApplicationContext()方法，将bean

所在的应用上下文的引用传入进来；

如果bean实现了BeanPostProcessor接口，Spring将调用它们的post

ProcessBeforeInitialization()方法；

如果bean实现了InitializingBean接口，Spring将调用它们的afterPropertiesSet()方法。类似地，如果

bean使用initmethod声明了初始化方法，

该方法也会被调用；

如果bean实现了BeanPostProcessor接口，Spring将调用它们的post

ProcessAfterInitialization()方法；此时，bean已经准备就绪，可以被应用程序使用了，它们将一直驻留

在应用上下文中，直到该应用上下文被销毁；

如果bean实现了DisposableBean接口，Spring将调用它的destroy()接口方

法。同样，如果bean使用destroy-method声明了销毁方法，该方法也会被调用。

现在你已经了解了如何创建和加载一个Spring容器。但是一个空的容器并没有太大的价值，在你把东西

放进去之前，它里面什么都没有。为了从Spring的

DI(依赖注入)中受益，我们必须将应用对象装配进Spring容器中。哪些是重要的bean生命周期方法？你能重载它们吗？

有两个重要的bean 生命周期方法，第一个是setup ，它是在容器加载bean的

时候被调用。第二个方法是 teardown 它是在容器卸载类的时候被调用。

bean 标签有两个重要的属性（init-method和destroy-method）。用它们你可以自己定制初始化和注销

方法。它们也有相应的注解（@PostConstruct和@PreDestroy）。

什么是Spring的内部bean？什么是Spring inner beans？

在Spring框架中，当一个bean仅被用作另一个bean的属性时，它能被声明为一个内部bean。内部bean

可以用setter注入“属性”和构造方法注入“构造参数”的方式来实现，内部bean通常是匿名的，它们的

Scope一般是prototype。

在 Spring中如何注入一个java集合？

Spring提供以下几种集合的配置元素：类型用于注入一列值，允许有相同的值。

类型用于注入一组值，不允许有相同的值。

类型用于注入一组键值对，键和值都只能为String类型。

什么是bean装配？

装配，或bean 装配是指在Spring 容器中把bean组装到一起，前提是容器需要知道bean的依赖关系，如

何通过依赖注入来把它们装配到一起。

什么是bean的自动装配？

在Spring框架中，在配置文件中设定bean的依赖关系是一个很好的机制，

Spring 容器能够自动装配相互合作的bean，这意味着容器不需要和配置，能通

过Bean工厂自动处理bean之间的协作。这意味着 Spring可以通过向Bean

Factory中注入的方式自动搞定bean之间的依赖关系。自动装配可以设置在每个bean上，也可以设定在

特定的bean上。

解释不同方式的自动装配，spring 自动装配 bean 有哪些方式？

在spring中，对象无需自己查找或创建与其关联的其他对象，由容器负责把需要相互协作的对象引用赋

予各个对象，使用autowire来配置自动装载模式。

在Spring框架xml配置中共有5种自动装配：

no：默认的方式是不进行自动装配的，通过手工设置ref属性来进行装配bean。

byName：通过bean的名称进行自动装配，如果一个bean的 property 与另一bean 的name 相

同，就进行自动装配。

byType：通过参数的数据类型进行自动装配。

constructor：利用构造函数进行装配，并且构造函数的参数通过 byType进行装配。

autodetect：自动探测，如果有构造方法，通过 construct的方式自动装配，否则使用 byType的方

式自动装配。使用@Autowired注解自动装配的过程是怎样的？

使用@Autowired注解来自动装配指定的bean。在使用@Autowired注解之前需要在Spring配置文件进

行配置，。

在启动spring IoC时，容器自动装载了一个

AutowiredAnnotationBeanPostProcessor后置处理器，当容器扫描到@Autowied、@Resource或

@Inject时，就会在IoC容器自动查找需要的 bean，并装配给该对象的属性。在使用@Autowired时，首

先在容器中查询对应类型的bean：

如果查询结果刚好为一个，就将该bean装配给@Autowired指定的数据；

如果查询的结果不止一个，那么@Autowired会根据名称来查找；

如果上述查找的结果为空，那么会抛出异常。解决方法时，使用required=false。

自动装配有哪些局限性？

自动装配的局限性是：重写：你仍需用和配置来定义依赖，意味着总要重写自动装配。

基本数据类型：你不能自动装配简单的属性，如基本数据类型，String字符串，和类。

模糊特性：自动装配不如显式装配精确，如果有可能，建议使用显式装配。

你可以在Spring中注入一个null 和一个空字符串吗？

可以

Spring注解

什么是基于Java的Spring注解配置? 给一些注解的例子

基于Java的配置，允许你在少量的Java注解的帮助下，进行你的大部分Spring 配置而非通过XML文件。

以@Configuration 注解为例，它用来标记类可以当做一个bean的定义，被

Spring IOC容器使用。

另一个例子是@Bean注解，它表示此方法将要返回一个对象，作为一个bean注册进Spring应用上下文。

怎样开启注解装配？

注解装配在默认情况下是不开启的，为了使用注解装配，我们必须在Spring配置文件中配置元素。

@Component, @Controller, @Repository, @Service 有何区别？

@Component：这将 java 类标记为 bean。它是任何 Spring 管理组件的通用构造型。spring 的组件扫

描机制现在可以将其拾取并将其拉入应用程序环境中。

@Controller：这将一个类标记为 Spring Web MVC 控制器。标有它的 Bean 会自动导入到 IoC 容器

中。

1 @Configuration

2 public class StudentConfig {

3 @Bean

4 public StudentBean myStudent() {

5 return new StudentBean();

6 }

7 }@Service：此注解是组件注解的特化。它不会对 @Component 注解提供任何其他行为。您可以在服务

层类中使用 @Service 而不是 @Component，因为它以更好的方式指定了意图。

@Repository：这个注解是具有类似用途和功能的 @Component 注解的特化。它为 DAO 提供了额外的

好处。它将 DAO 导入 IoC 容器，并使未经检查的异常有资格转换为 Spring DataAccessException。

@Required 注解有什么作用

这个注解表明bean的属性必须在配置的时候设置，通过一个bean定义的显式的属性值或通过自动装

配，若@Required注解的bean属性未被设置，容器将抛出

BeanInitializationException。示例：

@Autowired 注解有什么作用

@Autowired默认是按照类型装配注入的，默认情况下它要求依赖对象必须存在（可以设置它required

属性为false）。@Autowired 注解提供了更细粒度的控制，包括在何处以及如何完成自动装配。它的用

法和@Required一样，修饰 setter方法、构造器、属性或者具有任意名称和/或多个参数的PN方法。

@Autowired和@Resource之间的区别

@Autowired可用于：构造函数、成员变量、Setter方法

@Autowired和@Resource之间的区别

@Autowired默认是按照类型装配注入的，默认情况下它要求依赖对象必须存在（可以设置它required

属性为false）。

@Resource默认是按照名称来装配注入的，只有当找不到与名称匹配的bean才会按照类型来装配注入。

1 public class Employee {

2 private String name;

3 @Required

4 public void setName(String name){

5 this.name=name;

6 }

7 public string getName(){

8 return name;

9 }

10 }

1 public class Employee {

2 private String name;

3 @Autowired

4 public void setName(String name) {

5 this.name=name;

6 }

7 public string getName(){

8 return name;

9 }

10 }@Qualifier 注解有什么作用

当您创建多个相同类型的 bean 并希望仅使用属性装配其中一个 bean 时，您可以使用@Qualifier 注解

和 @Autowired 通过指定应该装配哪个确切的 bean 来消除歧义。

@RequestMapping 注解有什么用？

@RequestMapping 注解用于将特定 HTTP 请求方法映射到将处理相应请求的控制器中的特定类/方法。

此注释可应用于两个级别：

类级别：映射请求的 URL

方法级别：映射 URL 以及 HTTP 请求方法

Spring数据访问

解释对象/关系映射集成模块

Spring 通过提供ORM模块，支持我们在直接JDBC之上使用一个对象/关系映射映射(ORM)工具，Spring

支持集成主流的ORM框架，如Hiberate，JDO和 iBATIS，JPA，TopLink，JDO，OJB 。Spring的事务管

理同样支持以上所有ORM框架及JDBC。

在Spring框架中如何更有效地使用JDBC？

使用Spring JDBC 框架，资源管理和错误处理的代价都会被减轻。所以开发者

只需写statements 和 queries从数据存取数据，JDBC也可以在Spring框架提供的模板类的帮助下更有效

地被使用，这个模板叫JdbcTemplate

解释JDBC抽象和DAO模块

通过使用JDBC抽象和DAO模块，保证数据库代码的简洁，并能避免数据库资源错误关闭导致的问题，它

在各种不同的数据库的错误信息之上，提供了一个统一的异常访问层。它还利用Spring的AOP 模块给

Spring应用中的对象提供事务管理服务。

spring DAO 有什么用？

Spring DAO（数据访问对象）使得 JDBC，Hibernate 或 JDO 这样的数据访

问技术更容易以一种统一的方式工作。这使得用户容易在持久性技术之间切换。

它还允许您在编写代码时，无需考虑捕获每种技术不同的异常。

spring JDBC API 中存在哪些类？

JdbcTemplate

SimpleJdbcTemplate

NamedParameterJdbcTemplate

SimpleJdbcInsert

SimpleJdbcCallJdbcTemplate是什么

JdbcTemplate 类提供了很多便利的方法解决诸如把数据库数据转变成基本数据类型或对象，执行写好的

或可调用的数据库操作语句，提供自定义的数据错误处理。

使用Spring通过什么方式访问Hibernate？使用 Spring 访问

Hibernate 的方法有哪些？

在Spring中有两种方式访问Hibernate：

使用 Hibernate 模板和回调进行控制反转

ernateDAOSupport 并应用 AOP 拦截器节点

如何通扩展 Hib过HibernateDaoSupport将Spring和Hibernate 结

合起来？

用Spring的 SessionFactory 调用 LocalSessionFactory。集成过程分三步：

配置the Hibernate SessionFactory

继承HibernateDaoSupport实现一个DAO

在AOP支持的事务中装配

Spring支持的事务管理类型， spring 事务实现方式有哪些？

Spring支持两种类型的事务管理：编程式事务管理：这意味你通过编程的方式管理事务，给你带来极大

的灵活性，但是难维护。

声明式事务管理：这意味着你可以将业务代码和事务管理分离，你只需用注解和XML配置来管理事务。

Spring事务的实现方式和实现原理

Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，

spring是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过 binlog或者redo log实现的。

说一下Spring的事务传播行为

spring事务的传播行为说的是，当多个事务同时存在的时候，spring如何处理这些事务的行为。

① PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该

事务，该设置是最常用的设置。

② PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在

事务，就以非事务执行。

③ PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存

在事务，就抛出异常。

④ PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

⑤ PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂

起。

⑥ PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

⑦ PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按

REQUIRED属性执行。说一下 spring 的事务隔离？

spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置），其他四个隔离级别和

数据库的隔离级别一致：

1. ISOLATION_DEFAULT：用底层数据库的设置隔离级别，数据库设置的是什么我就用什么；

2. ISOLATION_READ_UNCOMMITTED：未提交读，最低隔离级别、事务未提交前，就可被其他事务

读取（会出现幻读、脏读、不可重复读）； 3. ISOLATION_READ_COMMITTED：提交读，一个事

务提交后才能被其他事务读取到（会造成幻读、不可重复读），SQL server 的默认级别；

3. ISOLATION_REPEATABLE_READ：可重复读，保证多次读取同一个数据时，其值都和事务开始时

候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读），MySQL 的默认级别；

4. ISOLATION_SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可

重复读、幻读。

脏读：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该

事务还未提交，然后另一个事务尝试读取到了记录 A。

不可重复读：是指在一个事务内，多次读同一数据。

幻读：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，

但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务

新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行

的记录就变多或者变少了。

Spring框架的事务管理有哪些优点？

为不同的事务API 如 JTA，JDBC，Hibernate，JPA 和JDO，提供一个不变的编程模式。

为编程式事务管理提供了一套简单的API而不是一些复杂的事务API 支持声明式事务管理。

和Spring各种数据访问抽象层很好得集成。

你更倾向用那种事务管理类型？

大多数Spring框架的用户选择声明式事务管理，因为它对应用代码的影响最小，因此更符合一个无侵入

的轻量级容器的思想。声明式事务管理要优于编程式事务管理，虽然比编程式事务管理（这种方式允许

你通过代码控制事务）少了一点灵活性。唯一不足地方是，最细粒度只能作用到方法级别，无法做到像

编程式事务那样可以作用到代码块级别。

Spring面向切面编程(AOP)什么是AOP

OOP(Object-Oriented Programming)面向对象编程，允许开发者定义纵向的关系，但并适用于定义横

向的关系，导致了大量代码的重复，而不利于各个模块的重用。

AOP(Aspect-Oriented Programming)，一般称为面向切面编程，作为面向对象的一种补充，用于将那

些与业务无关，但却对多个对象产生影响的公共行为和逻辑，抽取并封装为一个可重用的模块，这个模

块被命名为“切面”（Aspect），减少系统中的重复代码，降低了模块间的耦合度，同时提高了系统的可

维护性。可用于权限认证、日志、事务处理等。

Spring AOP and AspectJ AOP 有什么区别？AOP 有哪些实现方

式？

AOP实现的关键在于代理模式，AOP代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；

动态代理则以Spring AOP为代表。

（

1） AspectJ是静态代理的增强，所谓静态代理，就是AOP框架会在编译阶段生成AOP代理类，因此也

称为编译时增强，他会在编译阶段将AspectJ(切面)织入到Java字节码中，运行的时候就是增强之后的

AOP对象。（

2） Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是每次运行

时在内存中临时为方法生成一个AOP对象，这个AOP

对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。

JDK动态代理和CGLIB动态代理的区别

Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理：

JDK动态代理只提供接口的代理，不支持类的代理。核心InvocationHandler接口和Proxy类，

InvocationHandler 通过invoke()方法反射来调用目标类中的代码，动态地将横切逻辑和业务编织

在一起；接着，Proxy利用 InvocationHandler动态创建一个符合某一接口的的实例, 生成目标类的

代理对象。

如果代理类没有实现 InvocationHandler 接口，那么Spring AOP会选择使用CGLIB来动态代理目标

类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成指定

类的一个子类对象，并覆盖其中特定方法并添加增强代码，从而实现AOP。CGLIB是通过继承的方

式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。

静态代理与动态代理区别在于生成AOP代理对象的时机不同，相对来说AspectJ 的静态代理方式具有更

好的性能，但是AspectJ需要特定的编译器进行处理，而

Spring AOP则无需特定的编译器处理。

InvocationHandler 的 invoke(Object proxy,Method method,Object[]

args)：

proxy是最终生成的代理实例; method 是被代理目标实例的某个具体方法; args 是被代理目标实例某个

方法的具体入参, 在方法反射调用时使用。

如何理解 Spring 中的代理？

将 Advice 应用于目标对象后创建的对象称为代理。在客户端对象的情况下，目标对象和代理对象是相同

的。

Advice + Target Object = Proxy

解释一下Spring AOP里面的几个名词

（

1）切面（Aspect）：切面是通知和切点的结合。通知和切点共同定义了切面的全部内容。在Spring

AOP中，切面可以使用通用类（基于模式的风格）或者在普通类中以 @AspectJ 注解来实现。

（

2）连接点（Join point）：指方法，在Spring AOP中，一个连接点总是代表一个方法的执行。应用

可能有数以千计的时机应用通知。这些时机被称为连接点。连接点是在应用执行过程中能够插入切面的

一个点。这个点可以是调用方法时、抛出异常时、甚至修改一个字段时。切面代码可以利用这些点插入

到应用的正常流程之中，并添加新的行为。

（

3）通知（Advice）：在AOP术语中，切面的工作被称为通知。

（

4）切入点（Pointcut）：切点的定义会匹配通知所要织入的一个或多个连接点。我们通常使用明确

的类和方法名称，或是利用正则表达式定义所匹配的类和方法名称来指定这些切点。

（

5）引入（Introduction）：引入允许我们向现有类添加新方法或属性。

（

6）目标对象（Target Object）：被一个或者多个切面（aspect）所通知

（advise）的对象。它通常是一个代理对象。也有人把它叫做被通知

（adviced）对象。既然Spring AOP是通过运行时代理实现的，这个对象永远是一个被代理

（proxied）对象。（

7）织入（Weaving）：织入是把切面应用到目标对象并创建新的代理对象的过程。在目标对象的生

命周期里有多少个点可以进行织入：

编译期：切面在目标类编译时被织入。AspectJ的织入编译器是以这种方式织入切面的。

类加载期：切面在目标类加载到JVM时被织入。需要特殊的类加载器，它可以在目标类被引入应用

之前增强该目标类的字节码。AspectJ5的加载时织入就支持以这种方式织入切面。

运行期：切面在应用运行的某个时刻被织入。一般情况下，在织入切面时，AOP 容器会为目标对象

动态地创建一个代理对象。SpringAOP就是以这种方式织入切面。

Spring在运行时通知对象

通过在代理类中包裹切面，Spring在运行期把切面织入到Spring管理的bean

中。代理封装了目标类，并拦截被通知方法的调用，再把调用转发给真正的目标 bean。当代理拦截到方

法调用时，在调用目标bean方法之前，会执行切面逻辑。

直到应用需要被代理的bean时，Spring才创建代理对象。如果使用的是

ApplicationContext的话，在ApplicationContext从BeanFactory中加载所有 bean的时候，Spring才会

创建被代理的对象。因为Spring运行时才创建代理对象，所以我们不需要特殊的编译器来织入

SpringAOP的切面。

Spring只支持方法级别的连接点

因为Spring基于动态代理，所以Spring只支持方法连接点。Spring缺少对字段可以利用Aspect来补充。

连接点的支持，而且它不支持构造器连接点。方法之外的连接点拦截

功能，我们在Spring AOP 中，关注点和横切关注的区别是什么？在

spring aop 中 concern 和 cross-cutting concern 的不同之处

关注点（concern）是应用中一个模块的行为，一个关注点可能会被定义成一个我们想实现的一个功

能。

横切关注点（cross-cutting concern）是一个关注点，此关注点是整个应用都会使用的功能，并影响整

个应用，比如日志，安全和数据传输，几乎应用的每个模块都需要的功能。因此这些都属于横切关注

点。

Spring通知有哪些类型？

在AOP术语中，切面的工作被称为通知，实际上是程序执行时要通过

SpringAOP框架触发的代码段。

Spring切面可以应用5种类型的通知：

1. 前置通知（Before）：在目标方法被调用之前调用通知功能；

2. 后置通知（After）：在目标方法完成之后调用通知，此时不会关心方法的输出是什么；

3. 返回通知（After-returning ）：在目标方法成功执行之后调用通知；

4. 异常通知（After-throwing）：在目标方法抛出异常后调用通知；

5. 环绕通知（Around）：通知包裹了被通知的方法，在被通知的方法调用之前和调用之后执行自定

义的行为。

同一个aspect，不同advice的执行顺序：

①没有异常情况下的执行顺序：

around before advice before advice target method 执行 around after advice after advice

afterReturning②有异常情况下的执行顺序： around before advice before advice target method 执行 around after

advice after advice

afterThrowing:异常发生 java.lang.RuntimeException: 异常发生

什么是切面 Aspect？

aspect 由 pointcount 和 advice 组成，切面是通知和切点的结合。它既包含了横切逻辑的定义, 也包括

了连接点的定义. Spring AOP 就是负责实施切面的框架, 它将切面所定义的横切逻辑编织到切面所指定的

连接点中.

AOP 的工作重心在于如何将增强编织目标对象的连接点上, 这里包含两个工作:

如何通过 pointcut 和 advice 定位到特定的 joinpoint 上

如何在 advice 中编写切面代码.

可以简单地认为, 使用 @Aspect 注解的类就是切面.

解释基于XML Schema方式的切面实现

在这种情况下，切面由常规类以及基于XML的配置实现。解释基于注解的切面实现

在这种情况下(基于@AspectJ的实现)，涉及到的切面声明的风格与带有java5标注的普通java类一致。

有几种不同类型的自动代理？

BeanNameAutoProxyCreator

DefaultAdvisorAutoProxyCreator

Metadata autoproxyingSpringMVC面试题

什么是 SpringMvc？

答：SpringMvc 是 spring 的一个模块，基于 MVC 的一个框架，无需中间整合层来整合。

Spring MVC 的优点：答：

1）它是基于组件技术的.全部的应用对象,无论控制器和视图,还是业务对象之类的都是 java 组件.并且和

Spring 提供的其他基础结构紧密集成.

2）不依赖于 Servlet API(目标虽是如此,但是在实现的时候确实是依赖于 Servlet 的)

3）可以任意使用各种视图技术,而不仅仅局限于 JSP

4）支持各种请求资源的映射策略

5）它应是易于扩展的

SpringMVC 工作原理？答：

1）客户端发送请求到 DispatcherServlet

2）DispatcherServlet 查询 handlerMapping 找到处理请求的 Controller

3）Controller 调用业务逻辑后，返回 ModelAndView

4）DispatcherServlet 查询 ModelAndView，找到指定视图

5）视图将结果返回到客户端

SpringMVC 流程？答：

1）用户发送请求至前端控制器 DispatcherServlet。

2） DispatcherServlet 收到请求调用 HandlerMapping 处理器映射器。

3）处理器映射器找到具体的处理器(可以根据 xml 配置、注解进行查找)，生成处理器对象及处理器拦

截器(如果有则生成)一并返回给 DispatcherServlet。

4） DispatcherServlet 调用 HandlerAdapter 处理器适配器。

5） HandlerAdapter 经过适配调用具体的处理器(Controller，也叫后端控制器)。

6） Controller 执行完成返回 ModelAndView。

7） HandlerAdapter 将 controller 执行结果 ModelAndView 返回给 DispatcherServlet。

8） DispatcherServlet 将 ModelAndView 传给 ViewReslover 视图解析器。

9） ViewReslover 解析后返回具体 View。

10）DispatcherServlet 根据 View 进行渲染视图（即将模型数据填充至视图中）。

11）DispatcherServlet 响应用户。SpringMvc 的控制器是不是单例模式,如果是,有什么问题,怎么解决？

答：是单例模式,所以在多线程访问的时候有线程安全问题,不要用同步,会影响性能的,解决方案是在控制

器里面不能写字段。

如果你也用过 struts2.简单介绍下 springMVC 和 struts2 的区别有

哪些?

答：

1）springmvc 的入口是一个 servlet 即前端控制器，而 struts2 入口是一个 filter 过虑器。

2）springmvc 是基于方法开发(一个 url 对应一个方法)，请求参数传递到方法的形参，可以设计为单例

或多例(建议单例)，struts2 是基于类开发，传递参数是通过类的属性，只能设计为多例。

3）Struts 采用值栈存储请求和响应的数据，通过 OGNL 存取数据，springmvc 通过参数解析器是将

request 请求内容解析，并给方法形参赋值，将数据和视图封装成 ModelAndView 对象，最后又将

ModelAndView 中的模型数据通过 reques 域传输到页面。Jsp 视图解析器默认使用 jstl。

SpingMvc 中的控制器的注解一般用那个,有没有别的注解可以替代？

答：一般用@Conntroller 注解,表示是表现层,不能用用别的注解代替。

@RequestMapping 注解用在类上面有什么作用？

答：是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的

方法都是以该地址作为父路径。

怎么样把某个请求映射到特定的方法上面？

答：直接在方法上面加上注解@RequestMapping,并且在这个注解里面写上要拦截的路径

如果在拦截请求中,我想拦截 get 方式提交的方法,怎么配置？

答：可以在@RequestMapping 注解里面加上 method=RequestMethod.GET

怎么样在方法里面得到 Request,或者 Session？

答：直接在方法的形参中声明 request,SpringMvc 就自动把 request 对象传入

我想在拦截的方法里面得到从前台传入的参数,怎么得到？

答：直接在形参里面声明这个参数就可以,但必须名字和传过来的参数一样

如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么

样快速得到这个对象？

答：直接在方法中声明这个对象,SpringMvc 就自动会把属性赋值到这个对象里面。SpringMvc 中函数的返回值是什么？

答：返回值可以有很多类型,有 String, ModelAndView,当一般用 String 比较好。

SpringMVC 怎么样设定重定向和转发的？

答：在返回值前面加"forward:"就可以让结果转发,譬如"forward:user.do?name=method4" 在返回值前

面加"redirect:"就可以让返回值重定向,譬如"redirect:http://www.baidu.com"

SpringMvc 用什么对象从后台向前台传递数据的？

答：通过 ModelMap 对象,可以在这个对象里面用 put 方法,把对象加到里面,前台就可以通过 el 表达式

拿到。

SpringMvc 中有个类把视图和数据都合并的一起的,叫什么？

答：叫 ModelAndView。

怎么样把 ModelMap 里面的数据放入 Session 里面？

答：可以在类上面加上@SessionAttributes 注解,里面包含的字符串就是要放入 session 里面的 key

SpringMvc 怎么和 AJAX 相互调用的？答：

通过 Jackson 框架就可以把 Java 里面的对象直接转化成 Js 可以识别的 Json 对象。

具体步骤如下：

1）加入 Jackson.jar

2）在配置文件中配置 json 的映射

3）在接受 Ajax 方法里面可以直接返回 Object,List 等,但方法前面要加上@ResponseBody 注解

21、当一个方法向 AJAX 返回特殊对象,譬如 Object,List 等,需要做什么处理？答：要加上

@ResponseBody 注解 22、SpringMvc 里面拦截器是怎么写的

答：有两种写法,一种是实现接口,另外一种是继承适配器类,然后在 SpringMvc 的配置文件中配置拦截器

即可：

<mvc:interceptors>

<mvc:interceptor>

<mvc:mapping path="/modelMap.do" />

<bean class="com.et.action.MyHandlerInterceptorAdapter" />讲下 SpringMvc 的执行流程

答：系统启动的时候根据配置文件创建 spring 的容器, 首先是发送 http 请求到核心控制器

disPatherServlet，spring 容器通过映射器去寻找业务控制器，使用适配器找到相应的业务类，在进业

务类时进行数据封装，在封装前可能会涉及到类型转换，执行完业务类后使用

ModelAndView 进行视图转发，数据放在 model 中，用 map 传递数据进行页面显示。

Spring Boot（连老师）

Spring Boot概述

什么是 Spring Boot？

Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式解决方案，主要是简化了使用

Spring 的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。

Spring Boot 有哪些优点？

Spring Boot 主要有如下优点：

1. 容易上手，提升开发效率，为 Spring 开发提供一个更快、更广泛的入门体验。

2. 开箱即用，远离繁琐的配置。

3. 提供了一系列大型项目通用的非业务性功能，例如：内嵌服务器、安全管理、运行数据监控、运行

状况检查和外部化配置等。

4. 没有代码生成，也不需要XML配置。

5. 避免大量的 Maven 导入和各种版本冲突。

Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了以下

3 个注解：

@SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。

</mvc:interceptor>

</mvc:interceptors>@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源

自动配置功能： @SpringBootApplication(exclude

= { DataSourceAutoConfiguration.class })。

@ComponentScan：Spring组件扫描。

配置

什么是 JavaConfig？

Spring JavaConfig 是 Spring 社区的产品，它提供了配置 Spring IoC 容器的纯Java 方法。因此它有助于

避免使用 XML 配置。使用 JavaConfig 的优点在于：

（

1）面向对象的配置。由于配置被定义为 JavaConfig 中的类，因此用户可以

充分利用 Java 中的面向对象功能。一个配置类可以继承另一个，重写它的

@Bean 方法等。

（

2）减少或消除 XML 配置。基于依赖注入原则的外化配置的好处已被证明。

但是，许多开发人员不希望在 XML 和 Java 之间来回切换。JavaConfig 为开发人员提供了一种纯 Java 方

法来配置与 XML 配置概念相似的 Spring 容器。从

技术角度来讲，只使用 JavaConfig 配置类来配置容器是可行的，但实际上很多人认为将JavaConfig 与

XML 混合匹配是理想的。（

3）类型安全和重构友好。JavaConfig 提供了一种类型安全的方法来配置

Spring容器。由于 Java 5.0 对泛型的支持，现在可以按类型而不是按名称检索 bean，不需要任何强制

转换或基于字符串的查找。

Spring Boot 自动配置原理是什么？

注解 @EnableAutoConfiguration, @Configuration, @ConditionalOnClass 就是自动配置的核心，

@EnableAutoConfiguration 给容器导入META-INF/spring.factories 里定义的自动配置类。

筛选有效的自动配置类。

每一个自动配置类结合对应的 xxxProperties.java 读取配置文件进行自动配置功能

你如何理解 Spring Boot 配置加载顺序？

在 Spring Boot 里面，可以使用以下几种方式来加载配置。

1） properties文件；

2） YAML文件；

3）系统环境变量；

等等……

4）命令行参数；什么是 YAML？

YAML 是一种人类可读的数据序列化语言。它通常用于配置文件。与属性文件相比，如果我们想要在配

置文件中添加复杂的属性，YAML 文件就更加结构化，而且更少混淆。可以看出 YAML 具有分层配置数

据。YAML 配置的优势在哪里 ?

YAML 现在可以算是非常流行的一种配置文件格式了，无论是前端还是后端，都可以见到 YAML 配置。

那么 YAML 配置和传统的 properties 配置相比到底有哪些优势呢？

1. 配置有序，在一些特殊的场景下，配置有序很关键

2. 支持数组，数组中的元素可以是基本数据类型也可以是对象

3. 简洁

相比 properties 配置文件，YAML 还有一个缺点，就是不支持 @PropertySource 注解导入自定义的

YAML 配置。

Spring Boot 是否可以使用 XML 配置 ?

Spring Boot 推荐使用 Java 配置而非 XML 配置，但是 Spring Boot 中也可以使用 XML 配置，通过

@ImportResource 注解可以引入一个 XML 配置。 spring boot 核心配置文件是什么？

bootstrap.properties 和 application.properties 有何区别 ?

单纯做 Spring Boot 开发，可能不太容易遇到 bootstrap.properties 配置文

件，但是在结合 Spring Cloud 时，这个配置就会经常遇到了，特别是在需要加载一些远程配置文件的时

侯。

spring boot 核心的两个配置文件：

bootstrap (. yml 或者 . properties)：boostrap 由父 ApplicationContext 加载的，比 applicaton 优先

加载，配置在应用程序上下文的引导阶段生效。一般来说我们在 Spring Cloud Config 或者 Nacos 中会

用到它。且 boostrap 里面的属性不

能被覆盖；

application (. yml 或者 . properties)：由ApplicatonContext 加载，用于 spring boot 项目的自动化配

置。

什么是 Spring Profiles？

Spring Profiles 允许用户根据配置文件（dev，test，prod 等）来注册 bean。因此，当应用程序在开发

中运行时，只有某些 bean 可以加载，而在

PRODUCTION中，某些其他 bean 可以加载。假设我们的要求是 Swagger 文档仅适用于 QA 环境，并

且禁用所有其他文档。这可以使用配置文件来完成。Spring Boot 使得使用配置文件非常简单。

如何在自定义端口上运行 Spring Boot 应用程序？

为了在自定义端口上运行 Spring Boot 应用程序，您可以在

application.properties 中指定端口。server.port = 8090

安全

如何实现 Spring Boot 应用程序的安全性？

为了实现 Spring Boot 的安全性，我们使用 spring-boot-starter-security 依赖项，并且必须添加安全配

置。它只需要很少的代码。配置类将必须扩展

WebSecurityConfigurerAdapter 并覆盖其方法。比较一下 Spring Security 和 Shiro 各自的优缺点 ?

由于 Spring Boot 官方提供了大量的非常方便的开箱即用的 Starter ，包括

Spring Security 的 Starter ，使得在 Spring Boot 中使用 Spring Security 变得更加容易，甚至只需要添

加一个依赖就可以保护所有的接口，所以，如果是

Spring Boot 项目，一般选择 Spring Security 。当然这只是一个建议的组合，单纯从技术上来说，无论

怎么组合，都是没有问题的。Shiro 和 Spring

Security 相比，主要有如下一些特点：

1. Spring Security 是一个重量级的安全管理框架；Shiro 则是一个轻量级

的安全管理框架

2. Spring Security 概念复杂，配置繁琐；Shiro 概念简单、配置简单

3. Spring Security 功能强大；Shiro 功能简单

Spring Boot 中如何解决跨域问题 ?

跨域可以在前端通过 JSONP 来解决，但是 JSONP 只可以发送 GET 请求，无法发送其他类型的请求，在

RESTful 风格的应用中，就显得非常鸡肋，因此我们推荐在后端通过（CORS，Cross-origin resource

sharing）来解决跨域问题。这种解决方案并非 Spring Boot 特有的，在传统的 SSM 框架中，就可以通

过 CORS 来解决跨域问题，只不过之前我们是在 XML 文件中配置 CORS ，现在可以通过实现

WebMvcConfigurer接口然后重写addCorsMappings方法解决跨域问题。

项目中前后端分离部署，所以需要解决跨域的问题。

我们使用cookie存放用户登录的信息，在spring拦截器进行权限控制，当权限不符合时，直接返回给用

户固定的json结果。

当用户登录以后，正常使用；当用户退出登录状态时或者token过期时，由于拦截器和跨域的顺序有问

题，出现了跨域的现象。

我们知道一个http请求，先走filter，到达servlet后才进行拦截器的处理，如果我们把cors放在filter里，

就可以优先于权限拦截器执行。

1 @Configuration

2 public class CorsConfig implements WebMvcConfigurer { 3

4 @Override

5 public void addCorsMappings(CorsRegistry registry) {

6 registry.addMapping("/**")

7 .allowedOrigins("*")

8 .allowCredentials(true)

9 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")

10 .maxAge(3600);

11 }

13 }

1 @Configuration

2 public class CorsConfig { 3

4 @Bean

5 public CorsFilter corsFilter() {

6 CorsConfiguration corsConfiguration = new CorsConfiguration();

7 corsConfiguration.addAllowedOrigin("*");

8 corsConfiguration.addAllowedHeader("*");什么是 CSRF 攻击？

CSRF 代表跨站请求伪造。这是一种攻击，迫使终用户在当前通过身份验证的 Web 应用程序上执行不需

要的操作。CSRF 攻击专门针对状态改变请求，而不是数据窃取，因为攻击者无法查看对伪造请求的响

应。

监视器

Spring Boot 中的监视器是什么？

Spring boot actuator 是 spring 启动框架中的重要功能之一。Spring boot 监视器可帮助您访问生产环

境中正在运行的应用程序的当前状态。有几个指标必须在生产环境中进行检查和监控。即使一些外部应

用程序可能正在使用这些服务来向相关人员触发警报消息。监视器模块公开了一组可直接作为 HTTP

URL 访问的REST 端点来检查状态。

如何在 Spring Boot 中禁用 Actuator 端点安全性？

默认情况下，所有敏感的 HTTP 端点都是安全的，只有具有 ACTUATOR 角色

的用户才能访问它们。安全性是使用标准的 HttpServletRequest.isUserInRole 方法实施的。我们可以

使用来禁用安全性。只有在执行机构端点在防火墙后访问时，才建议禁用安全性。

我们如何监视所有 Spring Boot 微服务？

Spring Boot 提供监视器端点以监控各个微服务的度量。这些端点对于获取有关应用程序的信息（如它

们是否已启动）以及它们的组件（如数据库等）是否正常运行很有帮助。但是，使用监视器的一个主要

缺点或困难是，我们必须单独打开应用程序的知识点以了解其状态或健康状况。想象一下涉及 50 个应

用程序的微服务，管理员将不得不击中所有 50 个应用程序的执行终端。为了帮助我们处理这种情况，

我们将使用位于的开源项目。它建立在 Spring Boot Actuator 之上，它提供了一个 Web UI，使我们能

够可视化多个应用程序的度量。

整合第三方项目

什么是 WebSockets？

WebSocket 是一种计算机通信协议，通过单个 TCP 连接提供全双工通信信道。

1、 WebSocket 是双向的 -使用 WebSocket 客户端或服务器可以发起消息发送。

2、 WebSocket 是全双工的 -客户端和服务器通信是相互独立的。

3、单个 TCP 连接 -初始连接使用 HTTP，然后将此连接升级到基于套接字的连接。然后这个单一连接

用于所有未来的通信

4、 Light -与 http 相比，WebSocket 消息数据交换要轻得多。

9 corsConfiguration.addAllowedMethod("*");

10 corsConfiguration.setAllowCredentials(true);

11 UrlBasedCorsConfigurationSource urlBasedCorsConfigurationSource = new U

rlBasedCorsConfigurationSource();

12 urlBasedCorsConfigurationSource.registerCorsConfiguration("/**", corsCo

nfiguration);

13 return new CorsFilter(urlBasedCorsConfigurationSource);

14 }

16 }什么是 Spring Data ?

Spring Data 是 Spring 的一个子项目。用于简化数据库访问，支持NoSQL 和关系数据存储。其主要目

标是使数据库的访问变得方便快捷。Spring Data 具有如下特点：

SpringData 项目支持 NoSQL 存储：

1. MongoDB （文档数据库）

2. Neo4j（图形数据库）

3. Redis（键/值存储）

4. Hbase（列族数据库）

SpringData 项目所支持的关系数据存储技术：

1. JDBC

2. JPA

Spring Data Jpa 致力于减少数据访问层 (DAO) 的开发量. 开发者唯一要做的，就是声明持久层的接口，

其他都交给 Spring Data JPA 来帮你完成！Spring Data JPA 通过规范方法的名字，根据符合规范的名字

来确定方法需要实现什么样的逻辑。

什么是 Spring Batch？

Spring Boot Batch 提供可重用的函数，这些函数在处理大量记录时非常重要，包括日志/跟踪，事务管

理，作业处理统计信息，作业重新启动，跳过和资源管理。它还提供了更先进的技术服务和功能，通过

优化和分区技术，可以实现极高批量和高性能批处理作业。简单以及复杂的大批量批处理作业可以高度

可扩展的方式利用框架处理重要大量的信息。

什么是 FreeMarker 模板？

FreeMarker 是一个基于 Java 的模板引擎，初专注于使用 MVC 软件架构进行动态网页生成。使用

Freemarker 的主要优点是表示层和业务层的完全分离。程序员可以处理应用程序代码，而设计人员可

以处理 html 页面设计。后使用 freemarker 可以将这些结合起来，给出终的输出页面。

如何集成 Spring Boot 和 ActiveMQ？

对于集成 Spring Boot 和 ActiveMQ，我们使用依赖关系。它只需要很少的配置，并且不需要样板代

码。

什么是 Apache Kafka？

Apache Kafka 是一个分布式发布 - 订阅消息系统。它是一个可扩展的，容错的发布 - 订阅消息系统，它

使我们能够构建分布式应用程序。这是一个 Apache 顶级项目。Kafka 适合离线和在线消息消费。

什么是 Swagger？你用 Spring Boot 实现了它吗？

Swagger 广泛用于可视化 API，使用 Swagger UI 为前端开发人员提供在线沙箱。Swagger 是用于生成

RESTful Web 服务的可视化表示的工具，规范和完整框架实现。它使文档能够以与服务器相同的速度更

新。当通过 Swagger 正确定义时，消费者可以使用少量的实现逻辑来理解远程服务并与其进行交互。

因此，Swagger消除了调用服务时的猜测。

前后端分离，如何维护接口文档 ?

前后端分离开发日益流行，大部分情况下，我们都是通过 Spring Boot 做前后端分离开发，前后端分离

一定会有接口文档，不然会前后端会深深陷入到扯皮中。一个比较笨的方法就是使用 word 或者 md 来

维护接口文档，但是效率太低，接口一变，所有人手上的文档都得变。在 Spring Boot 中，这个问题常

见的解决方案是 Swagger ，使用 Swagger 我们可以快速生成一个接口文档网

站，接口一旦发生变化，文档就会自动更新，所有开发工程师访问这一个在线网站就可以获取到新的接

口文档，非常方便。

其他

如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？

Spring Boot项目如何热部署？

这可以使用 DEV 工具来实现。通过这种依赖关系，您可以节省任何更改，嵌入式tomcat 将重新启动。

Spring Boot 有一个开发工具（DevTools）模块，它有助于提高开发人员的生产力。Java 开发人员面临

的一个主要挑战是将文件更改自动部署到服务器并自动重启服务器。开发人员可以重新加载 Spring

Boot 上的更改，而无需重新启动服务器。这将消除每次手动部署更改的需要。

Spring Boot 在发布它的第一个版本时没有这个功能。这是开发人员需要的功能。DevTools 模块完全满

足开发人员的需求。该模块将在生产环境中被禁用。

它还提供 H2 数据库控制台以更好地测试应用程序。

您使用了哪些 starter maven 依赖项？

使用了下面的一些依赖项

spring-boot-starter-activemq

spring-boot-starter-security

这有助于增加更少的依赖关系，并减少版本的冲突。

Spring Boot 中的 starter 到底是什么 ?

首先，这个 Starter 并非什么新的技术点，基本上还是基于 Spring 已有功能来实现的。首先它提供了一

个自动化配置类，一般命名为 XXXAutoConfiguration

，在这个配置类中通过条件注解来决定一个配置是否生效（条件注解就是

Spring 中原本就有的），然后它还会提供一系列的默认配置，也允许开发者根据实际情况自定义相关配

置，然后通过类型安全的属性注入将这些配置属性注入进来，新注入的属性会代替掉默认属性。正因为

如此，很多第三方框架，我们只需要引入依赖就可以直接使用了。当然，开发者也可以自定义 Starter

spring-boot-starter-parent 有什么用 ?

我们都知道，新创建一个 Spring Boot 项目，默认都是有 parent 的，这个

parent 就是 spring-boot-starter-parent ，spring-boot-starter-parent 主要有如下作用：

1. 定义了 Java 编译版本为 1.8 。

2. 使用 UTF-8 格式编码。

3. 继承自 spring-boot-dependencies，这个里边定义了依赖的版本，也正是因为继承了这个依赖，

所以我们在写依赖时才不需要写版本号。

4. 执行打包操作的配置。

5. 自动化的资源过滤。

6. 自动化的插件配置。

1 <dependency>

2 <groupId>org.springframework.boot</groupId>

3 <artifactId>spring-boot-devtools</artifactId>

4 </dependency>7. 针对 application.properties 和 application.yml 的资源过滤，包括通过 profile 定义的不同环境的

配置文件，例如 applicationdev.properties 和 application-dev.yml。

Spring Boot 打成的 jar 和普通的 jar 有什么区别 ?

Spring Boot 项目终打包成的 jar 是可执行 jar ，这种 jar 可以直接通过 java jar xxx.jar 命令来运行，

这种 jar 不可以作为普通的 jar 被其他项目依赖，即使依赖了也无法使用其中的类。

Spring Boot 的 jar 无法被其他项目依赖，主要还是他和普通 jar 的结构不同。普通的 jar 包，解压后直

接就是包名，包里就是我们的代码，而 Spring Boot

打包成的可执行 jar 解压后，在 \BOOT-INF\classes 目录下才是我们的代码，因此无法被直接引用。如

果非要引用，可以在 pom.xml 文件中增加配置，将 Spring Boot 项目打包成两个 jar ，一个可执行，一

个可引用。

运行 Spring Boot 有哪几种方式？

1）打包用命令或者放到容器中运行

2）用 Maven/ Gradle 插件运行

3）直接执行 main 方法运行

Spring Boot 需要独立的容器运行吗？

开启 Spring Boot 特性有哪几种方式？

1）继承spring-boot-starter-parent项目

2）导入spring-boot-dependencies项目依赖

如何使用 Spring Boot 实现异常处理？

Spring 提供了一种使用 ControllerAdvice 处理异常的非常有用的方法。我们通过实现一个

ControlerAdvice 类，来处理控制器类抛出的所有异常。

如何使用 Spring Boot 实现分页和排序？

使用 Spring Boot 实现分页非常简单。使用 Spring Data-JPA 可以实现将可分页的传递给存储库方法。

微服务中如何实现 session 共享 ?

在微服务中，一个完整的项目被拆分成多个不相同的独立的服务，各个服务独立部署在不同的服务器

上，各自的 session 被从物理空间上隔离开了，但是经

常，我们需要在不同微服务之间共享 session ，常见的方案就是 Spring

Session + Redis 来实现 session 共享。将所有微服务的 session 统一保存在 Redis 上，当各个微服务对

session 有相关的读写操作时，都去操作 Redis 上的 session 。这样就实现了 session 共享，Spring

Session 基于 Spring 中的代理过滤器实现，使得 session 的同步操作对开发人员而言是透明的，非常简

便。

Spring Boot 中如何实现定时任务 ?

定时任务也是一个常见的需求，Spring Boot 中对于定时任务的支持主要还是来自 Spring 框架。

在 Spring Boot 中使用定时任务主要有两种不同的方式，一个就是使用 Spring 中的 @Scheduled 注

解，另一个则是使用第三方框架 Quartz。

使用 Spring 中的 @Scheduled 的方式主要通过 @Scheduled 注解来实现。使用 Quartz ，则按照 Quartz 的方式，定义 Job 和 Trigger 即可。

Spring Boot 原理

Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及

开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这

种方式，Spring Boot 致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导

者。其特点如下：

1. 创建独立的 Spring 应用程序

2. 嵌入的 Tomcat，无需部署 WAR 文件

3. 简化 Maven 配置

4. 自动配置 Spring

5. 提供生产就绪型功能，如指标，健康检查和外部配置

6. 绝对没有代码生成和对 XML 没有要求配置 [1]

Spring Boot比Spring做了哪些改进？

1）Spring Boot可以建立独立的Spring应用程序；

2）内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作

了；

3）无需再像Spring那样搞一堆繁琐的xml文件的配置；

4）可以自动配置Spring。SpringBoot将原有的XML配置改为Java配置，将bean注入改为使用注解注入

的方式(@Autowire)，并将多个xml、properties配置浓缩在一个appliaction.yml 配置文件中。

5）提供了一些现有的功能，如量度工具，表单数据验证以及一些外部配置这样的一些第三方功能；

6）整合常用依赖（开发库，例如spring-webmvc、jackson-json、validation-api和tomcat 等），提供

的POM可以简化Maven的配置。当我们引入核心依赖时，SpringBoot会自引入其他依赖。

Spring boot 热加载在实际的开发中避免不了自己测试的时候修修改改，甚至有些源代码的修改是需要重启项目的，这个时

候热加载就帮了大忙了，其会自动将修改的代码应用到部署的项目中去，而不用自己再次的去手动重

启，大大的提高了我们开发的效率，实现了代码随时改效果立马生效的效果，好了废话不多说了，下面

来介绍怎解嵌入热加载的实现。

在pom文件中添加依赖（optional-->true表示覆盖父级项目中的引用）：

org.springframework.boot </ groupId>

spring-boot-devtools </ artifactId>

true </ optional>

</ dependency>

就是这么简单，这样就可以了，当然了，有些时候我们再修改一些文件时是并不希望其触发重启的，例

如一些静态资源等，此时我们可以设置一些排序路径来将其排除出去，在此之前先来介绍一下触发重启

的条件吧：当DevTools监视类路径资源时，触发重新启动的唯一方法是更新类路径。导致类路径更新的

方式取决于您正在使用的IDE。在Eclipse中，保存修改的文件将导致类路径被更新并触发重新启动。在

IntelliJ IDEA中，构建project（Build -> Make Project）将具有相同的效果。

如果要自定义一些排除项，您可以使用该spring.devtools.restart.exclude属性。例如，仅排除 /static

和/public你设置如下：

spring.devtools.restart.exclude=static/,public/

当您对不在类路径中的文件进行更改时，可能需要重新启动或重新加载应用程序。为此，请使用该

spring.devtools.restart.additional-paths属性配置其他路径来监视更改。

如果您不想使用重新启动功能，可以使用该spring.devtools.restart.enabled属性禁用它。在大多数情

况下，您可以将其设置为 application.properties（仍将初始化重新启动类加载器，但不会监视文件更

改）。

例如，如果您需要完全禁用重新启动支持，因为它不适用于特定库，则需要System在调用之前设置属

性 SpringApplication.run(…)。例如：

public static void main(String[] args) {

System.setProperty("spring.devtools.restart.enabled", "false");

SpringApplication.run(MyApp.class, args);

}

我不知道大家都使用的是什么IDE，我现在用的是IntelliJ IDEA，而这个工具有各特点就是编辑文件后其

会立刻自动保存，并不需要手动的Ctrl+s来操作，造成的结果就是每当我修改一个触发启动的文件的时

候其就会自动进行热加载，而我们并不想这样频繁的去热加载的话，可以进行一些特殊的设计实现仅在

特定的时间去触发热加载：我们可以使用“触发文件”，这是一个特殊文件，当您要实际触发重新启动检

查时，必须修改它。更改文件只会触发检查，只有在Devtools检测到它必须执行某些操作时才会重新启

动。触发文件可以手动更新，也可以通过IDE插件更新。要使用触发器文件使用该

spring.devtools.restart.trigger-file属性。

Spring Boot设置有效时间和自动刷新缓存，时间支持在配

置文件中配置Spring Boot缓存实战 Redis 设置有效时间和自动刷新缓存，时间支

持在配置文件中配置

问题描述

Spring Cache提供的@Cacheable注解不支持配置过期时间，还有缓存的自动刷新。

我们可以通过配置CacheManneg来配置默认的过期时间和针对每个缓存容器（value）单独配置过期时

间，但是总是感觉不太灵活。下面是一个示例:

我们想在注解上直接配置过期时间和自动刷新时间，就像这样：

value属性上用#号隔开，第一个是原始的缓存容器名称，第二个是缓存的有效时间，第三个是缓存的自

动刷新时间，单位都是秒。

缓存的有效时间和自动刷新时间支持SpEl表达式，支持在配置文件中配置，如：

解决思路

查看源码你会发现缓存最顶级的接口就是CacheManager和Cache接口。

@Bean

public CacheManager cacheManager(RedisTemplate redisTemplate) {

RedisCacheManager cacheManager= new RedisCacheManager(redisTemplate);

cacheManager.setDefaultExpiration(60);

Map<String,Long> expiresMap=new HashMap<>();

expiresMap.put("Product",5L);

cacheManager.setExpires(expiresMap);

return cacheManager;

}

@Cacheable(value = "people#120#90", key = "#person.id")

public Person findOne(Person person) {

Person p = personRepository.findOne(person.getId());

System.out.println("为id、key为:" + p.getId() + "数据做了缓存");

return p;

}

@Cacheable(value =

"people#${select.cache.timeout:1800}#${select.cache.refresh:600}", key =

"#person.id", sync = true)//3

public Person findOne(Person person) {

Person p = personRepository.findOne(person.getId());

System.out.println("为id、key为:" + p.getId() + "数据做了缓存");

return p;

}CacheManager说明

CacheManager功能其实很简单就是管理cache，接口只有两个方法，根据容器名称获取一个Cache。还

有就是返回所有的缓存名称。

Cache说明

Cache接口主要是操作缓存的。get根据缓存key从缓存服务器获取缓存中的值，put根据缓存key将数据

放到缓存服务器，evict根据key删除缓存中的数据。

请求步骤

1. 请求进来，在方法上面扫描@Cacheable注解，那么会触发

org.springframework.cache.interceptor.CacheInterceptor缓存的拦截器。

2. 然后会调用CacheManager的getCache方法，获取Cache，如果没有（第一次访问）就新建一

Cache并返回。

3. 根据获取到的Cache去调用get方法获取缓存中的值。RedisCache这里有个bug，源码是先判断key

是否存在，再去缓存获取值，在高并发下有bug。

代码分析

在最上面我们说了Spring Cache可以通过配置CacheManager来配置过期时间。那么这个过期时间是在

哪里用的呢？设置默认的时间setDefaultExpiration，根据特定名称设置有效时间setExpires，获取一个

缓存名称（value属性）的有效时间computeExpiration，真正使用有效时间是在createCache方法里

面，而这个方法是在父类的getCache方法调用。通过RedisCacheManager源码我们看到：

public interface CacheManager {

/**

* 根据名称获取一个Cache（在实现类里面是如果有这个Cache就返回，没有就新建一个Cache放到

Map容器中）

* @param name the cache identifier (must not be {@code null})

* @return the associated cache, or {@code null} if none found

Cache getCache(String name);

/**

* 返回一个缓存名称的集合

* @return the names of all caches known by the cache manager

Collection<String> getCacheNames();

}

public interface Cache {

ValueWrapper get(Object key);

void put(Object key, Object value);

void evict(Object key);

...

}// 设置默认的时间

public void setDefaultExpiration(long defaultExpireTime) {

this.defaultExpiration = defaultExpireTime;

}

// 根据特定名称设置有效时间

public void setExpires(Map<String, Long> expires) {

this.expires = (expires != null ? new ConcurrentHashMap<String, Long>

(expires) : null);

}

// 获取一个key的有效时间

protected long computeExpiration(String name) {

Long expiration = null;

if (expires != null) {

expiration = expires.get(name);

}

return (expiration != null ? expiration.longValue() : defaultExpiration);

}

@SuppressWarnings("unchecked")

protected RedisCache createCache(String cacheName) {

// 调用了上面的方法获取缓存名称的有效时间

long expiration = computeExpiration(cacheName);

// 创建了Cache对象，并使用了这个有效时间

return new RedisCache(cacheName, (usePrefix ? cachePrefix.prefix(cacheName)

: null), redisOperations, expiration,

cacheNullValues);

}

// 重写父类的getMissingCache。去创建Cache

@Override

protected Cache getMissingCache(String name) {

return this.dynamic ? createCache(name) : null;

}

AbstractCacheManager父类源码：

// 根据名称获取Cache如果没有调用getMissingCache方法，生成新的Cache，并将其放到Map容器中去。

@Override

public Cache getCache(String name) {

Cache cache = this.cacheMap.get(name);

if (cache != null) {

return cache;

}

else {

// Fully synchronize now for missing cache creation...

synchronized (this.cacheMap) {

cache = this.cacheMap.get(name);

if (cache == null) {

// 如果没找到Cache调用该方法，这个方法默认返回值NULL由子类自己实现。上面的

就是子类自己实现的方法

cache = getMissingCache(name);

if (cache != null) {

cache = decorateCache(cache);

this.cacheMap.put(name, cache);

updateCacheNames(name);

}}

return cache;

}

由此这个有效时间的设置关键就是在getCache方法上，这里的name参数就是我们注解上的value属性。

所以在这里解析这个特定格式的名称我就可以拿到配置的过期时间和刷新时间。getMissingCache方法

里面在新建缓存的时候将这个过期时间设置进去，生成的Cache对象操作缓存的时候就会带上我们的配

置的过期时间，然后过期就生效了。解析SpEL表达式获取配置文件中的时间也在也一步完成。

CustomizedRedisCacheManager源码：

package com.xiaolyuh.redis.cache;

import com.xiaolyuh.redis.cache.helper.SpringContextHolder;

import com.xiaolyuh.redis.utils.ReflectionUtils;

import org.apache.commons.lang3.StringUtils;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.beans.factory.support.DefaultListableBeanFactory;

import org.springframework.cache.Cache;

import org.springframework.data.redis.cache.RedisCacheManager;

import org.springframework.data.redis.core.RedisOperations;

import java.util.Collection;

import java.util.concurrent.ConcurrentHashMap;

/**

* 自定义的redis缓存管理器

* 支持方法上配置过期时间

* 支持热加载缓存：缓存即将过期时主动刷新缓存

* @author yuhao.wang

public class CustomizedRedisCacheManager extends RedisCacheManager {

private static final Logger logger =

LoggerFactory.getLogger(CustomizedRedisCacheManager.class);

/**

* 父类cacheMap字段

private static final String SUPER_FIELD_CACHEMAP = "cacheMap";

/**

* 父类dynamic字段

private static final String SUPER_FIELD_DYNAMIC = "dynamic";

/**

* 父类cacheNullValues字段

private static final String SUPER_FIELD_CACHENULLVALUES = "cacheNullValues";

/**

* 父类updateCacheNames方法*/

private static final String SUPER_METHOD_UPDATECACHENAMES =

"updateCacheNames";

/**

* 缓存参数的分隔符

* 数组元素0=缓存的名称

* 数组元素1=缓存过期时间TTL

* 数组元素2=缓存在多少秒开始主动失效来强制刷新

private static final String SEPARATOR = "#";

/**

* SpEL标示符

private static final String MARK = "$";

RedisCacheManager redisCacheManager = null;

@Autowired

DefaultListableBeanFactory beanFactory;

public CustomizedRedisCacheManager(RedisOperations redisOperations) {

super(redisOperations);

}

public CustomizedRedisCacheManager(RedisOperations redisOperations,

Collection<String> cacheNames) {

super(redisOperations, cacheNames);

}

public RedisCacheManager getInstance() {

if (redisCacheManager == null) {

redisCacheManager =

SpringContextHolder.getBean(RedisCacheManager.class);

}

return redisCacheManager;

}

@Override

public Cache getCache(String name) {

String[] cacheParams = name.split(SEPARATOR);

String cacheName = cacheParams[0];

if (StringUtils.isBlank(cacheName)) {

return null;

}

// 有效时间，初始化获取默认的有效时间

Long expirationSecondTime = getExpirationSecondTime(cacheName,

cacheParams);

// 自动刷新时间，默认是0

Long preloadSecondTime = getExpirationSecondTime(cacheParams);

// 通过反射获取父类存放缓存的容器对象

Object object = ReflectionUtils.getFieldValue(getInstance(),

SUPER_FIELD_CACHEMAP);

if (object != null && object instanceof ConcurrentHashMap) {ConcurrentHashMap<String, Cache> cacheMap =

(ConcurrentHashMap<String, Cache>) object;

// 生成Cache对象，并将其保存到父类的Cache容器中

return getCache(cacheName, expirationSecondTime, preloadSecondTime,

cacheMap);

} else {

return super.getCache(cacheName);

}

/**

* 获取过期时间

* @return

private long getExpirationSecondTime(String cacheName, String[] cacheParams)

{

// 有效时间，初始化获取默认的有效时间

Long expirationSecondTime = this.computeExpiration(cacheName);

// 设置key有效时间

if (cacheParams.length > 1) {

String expirationStr = cacheParams[1];

if (!StringUtils.isEmpty(expirationStr)) {

// 支持配置过期时间使用EL表达式读取配置文件时间

if (expirationStr.contains(MARK)) {

expirationStr =

beanFactory.resolveEmbeddedValue(expirationStr);

}

expirationSecondTime = Long.parseLong(expirationStr);

}

return expirationSecondTime;

}

/**

* 获取自动刷新时间

* @return

private long getExpirationSecondTime(String[] cacheParams) {

// 自动刷新时间，默认是0

Long preloadSecondTime = 0L;

// 设置自动刷新时间

if (cacheParams.length > 2) {

String preloadStr = cacheParams[2];

if (!StringUtils.isEmpty(preloadStr)) {

// 支持配置刷新时间使用EL表达式读取配置文件时间

if (preloadStr.contains(MARK)) {

preloadStr = beanFactory.resolveEmbeddedValue(preloadStr);

}

preloadSecondTime = Long.parseLong(preloadStr);

}

return preloadSecondTime;

}/**

* 重写父类的getCache方法，真假了三个参数

* @param cacheName 缓存名称

* @param expirationSecondTime 过期时间

* @param preloadSecondTime 自动刷新时间

* @param cacheMap 通过反射获取的父类的cacheMap对象

* @return Cache

public Cache getCache(String cacheName, long expirationSecondTime, long

preloadSecondTime, ConcurrentHashMap<String, Cache> cacheMap) {

Cache cache = cacheMap.get(cacheName);

if (cache != null) {

return cache;

} else {

// Fully synchronize now for missing cache creation...

synchronized (cacheMap) {

cache = cacheMap.get(cacheName);

if (cache == null) {

// 调用我们自己的getMissingCache方法创建自己的cache

cache = getMissingCache(cacheName, expirationSecondTime,

preloadSecondTime);

if (cache != null) {

cache = decorateCache(cache);

cacheMap.put(cacheName, cache);

// 反射去执行父类的updateCacheNames(cacheName)方法

Class<?>[] parameterTypes = {String.class};

Object[] parameters = {cacheName};

ReflectionUtils.invokeMethod(getInstance(),

SUPER_METHOD_UPDATECACHENAMES, parameterTypes, parameters);

}

return cache;

}

/**

* 创建缓存

* @param cacheName 缓存名称

* @param expirationSecondTime 过期时间

* @param preloadSecondTime 制动刷新时间

* @return

public CustomizedRedisCache getMissingCache(String cacheName, long

expirationSecondTime, long preloadSecondTime) {

logger.info("缓存 cacheName：{}，过期时间:{}, 自动刷新时间:{}", cacheName,

expirationSecondTime, preloadSecondTime);

Boolean dynamic = (Boolean) ReflectionUtils.getFieldValue(getInstance(),

SUPER_FIELD_DYNAMIC);

Boolean cacheNullValues = (Boolean)

ReflectionUtils.getFieldValue(getInstance(), SUPER_FIELD_CACHENULLVALUES);return dynamic ? new CustomizedRedisCache(cacheName, (this.isUsePrefix()

? this.getCachePrefix().prefix(cacheName) : null),

this.getRedisOperations(), expirationSecondTime,

preloadSecondTime, cacheNullValues) : null;

}

那自动刷新时间呢？

在RedisCache的属性里面没有刷新时间，所以我们继承该类重写我们自己的Cache的时候要多加一个属

性preloadSecondTime来存储这个刷新时间。并在getMissingCache方法创建Cache对象的时候指定该

值。

CustomizedRedisCache部分源码：

/**

* 缓存主动在失效前强制刷新缓存的时间

* 单位：秒

private long preloadSecondTime = 0;

// 重写后的构造方法

public CustomizedRedisCache(String name, byte[] prefix, RedisOperations<?

extends Object, ? extends Object> redisOperations, long expiration, long

preloadSecondTime) {

super(name, prefix, redisOperations, expiration);

this.redisOperations = redisOperations;

// 指定自动刷新时间

this.preloadSecondTime = preloadSecondTime;

this.prefix = prefix;

}

// 重写后的构造方法

public CustomizedRedisCache(String name, byte[] prefix, RedisOperations<?

extends Object, ? extends Object> redisOperations, long expiration, long

preloadSecondTime, boolean allowNullValues) {

super(name, prefix, redisOperations, expiration, allowNullValues);

this.redisOperations = redisOperations;

// 指定自动刷新时间

this.preloadSecondTime = preloadSecondTime;

this.prefix = prefix;

}

那么这个自动刷新时间有了，怎么来让他自动刷新呢？

在调用Cache的get方法的时候我们都会去缓存服务查询缓存，这个时候我们在多查一个缓存的有效时

间，和我们配置的自动刷新时间对比，如果缓存的有效时间小于这个自动刷新时间我们就去刷新缓存

（这里注意一点在高并发下我们最好只放一个请求去刷新数据，尽量减少数据的压力，所以在这个位置

加一个分布式锁）。所以我们重写这个get方法。

CustomizedRedisCache部分源码：

/**

* 重写get方法，获取到缓存后再次取缓存剩余的时间，如果时间小余我们配置的刷新时间就手动刷新缓存。

* 为了不影响get的性能，启用后台线程去完成缓存的刷。

* 并且只放一个线程去刷新数据。

** @param key

* @return

@Override

public ValueWrapper get(final Object key) {

RedisCacheKey cacheKey = getRedisCacheKey(key);

String cacheKeyStr = new String(cacheKey.getKeyBytes());

// 调用重写后的get方法

ValueWrapper valueWrapper = this.get(cacheKey);

if (null != valueWrapper) {

// 刷新缓存数据

refreshCache(key, cacheKeyStr);

}

return valueWrapper;

}

/**

* 重写父类的get函数。

* 父类的get方法，是先使用exists判断key是否存在，不存在返回null，存在再到redis缓存中去取值。

这样会导致并发问题，

* 假如有一个请求调用了exists函数判断key存在，但是在下一时刻这个缓存过期了，或者被删掉了。

* 这时候再去缓存中获取值的时候返回的就是null了。

* 可以先获取缓存的值，再去判断key是否存在。

* @param cacheKey

* @return

@Override

public RedisCacheElement get(final RedisCacheKey cacheKey) {

Assert.notNull(cacheKey, "CacheKey must not be null!");

// 根据key获取缓存值

RedisCacheElement redisCacheElement = new RedisCacheElement(cacheKey,

fromStoreValue(lookup(cacheKey)));

// 判断key是否存在

Boolean exists = (Boolean) redisOperations.execute(new

RedisCallback<Boolean>() {

@Override

public Boolean doInRedis(RedisConnection connection) throws

DataAccessException {

return connection.exists(cacheKey.getKeyBytes());

}

});

if (!exists.booleanValue()) {

return null;

}

return redisCacheElement;

}

/**

* 刷新缓存数据

private void refreshCache(Object key, String cacheKeyStr) {Long ttl = this.redisOperations.getExpire(cacheKeyStr);

if (null != ttl && ttl <= CustomizedRedisCache.this.preloadSecondTime) {

// 尽量少的去开启线程，因为线程池是有限的

ThreadTaskHelper.run(new Runnable() {

@Override

public void run() {

// 加一个分布式锁，只放一个请求去刷新缓存

RedisLock redisLock = new RedisLock((RedisTemplate)

redisOperations, cacheKeyStr + "_lock");

try {

if (redisLock.lock()) {

// 获取锁之后再判断一下过期时间，看是否需要加载数据

Long ttl =

CustomizedRedisCache.this.redisOperations.getExpire(cacheKeyStr);

if (null != ttl && ttl <=

CustomizedRedisCache.this.preloadSecondTime) {

// 通过获取代理方法信息重新加载缓存数据

CustomizedRedisCache.this.getCacheSupport().refreshCacheByKey(CustomizedRedisCa

che.super.getName(), key.toString());

}

} catch (Exception e) {

logger.info(e.getMessage(), e);

} finally {

redisLock.unlock();

}

});

}

那么自动刷新肯定要掉用方法访问数据库，获取值后去刷新缓存。这时我们又怎么能去调用方法呢？

我们利用java的反射机制。所以我们要用一个容器来存放缓存方法的方法信息，包括对象，方法名称，

参数等等。我们创建了CachedInvocation类来存放这些信息，再将这个类的对象维护到容器中。

CachedInvocation源码：

public final class CachedInvocation {

private Object key;

private final Object targetBean;

private final Method targetMethod;

private Object[] arguments;

public CachedInvocation(Object key, Object targetBean, Method targetMethod,

Object[] arguments) {

this.key = key;

this.targetBean = targetBean;

this.targetMethod = targetMethod;

if (arguments != null && arguments.length != 0) {

this.arguments = Arrays.copyOf(arguments, arguments.length);

}

}public Object[] getArguments() {

return arguments;

}

public Object getTargetBean() {

return targetBean;

}

public Method getTargetMethod() {

return targetMethod;

}

public Object getKey() {

return key;

}

/**

* 必须重写equals和hashCode方法，否则放到set集合里没法去重

* @param o

* @return

@Override

public boolean equals(Object o) {

if (this == o) {

return true;

}

if (o == null || getClass() != o.getClass()) {

return false;

}

CachedInvocation that = (CachedInvocation) o;

return key.equals(that.key);

}

@Override

public int hashCode() {

return key.hashCode();

}

维护缓存方法信息的容器和刷新缓存的类CacheSupportImpl 关键代码：

private final String SEPARATOR = "#";

/**

* 记录缓存执行方法信息的容器。

* 如果有很多无用的缓存数据的话，有可能会照成内存溢出。

private Map<String, Set<CachedInvocation>> cacheToInvocationsMap = new

ConcurrentHashMap<>();

@Autowired

private CacheManager cacheManager;

// 刷新缓存

private void refreshCache(CachedInvocation invocation, String cacheName) {boolean invocationSuccess;

Object computed = null;

try {

// 通过代理调用方法，并记录返回值

computed = invoke(invocation);

invocationSuccess = true;

} catch (Exception ex) {

invocationSuccess = false;

}

if (invocationSuccess) {

if (!CollectionUtils.isEmpty(cacheToInvocationsMap.get(cacheName))) {

// 通过cacheManager获取操作缓存的cache对象

Cache cache = cacheManager.getCache(cacheName);

// 通过Cache对象更新缓存

cache.put(invocation.getKey(), computed);

}

private Object invoke(CachedInvocation invocation)

throws ClassNotFoundException, NoSuchMethodException,

InvocationTargetException, IllegalAccessException {

final MethodInvoker invoker = new MethodInvoker();

invoker.setTargetObject(invocation.getTargetBean());

invoker.setArguments(invocation.getArguments());

invoker.setTargetMethod(invocation.getTargetMethod().getName());

invoker.prepare();

return invoker.invoke();

}

// 注册缓存方法的执行类信息

@Override

public void registerInvocation(Object targetBean, Method targetMethod, Object[]

arguments,

Set<String> annotatedCacheNames, String cacheKey) {

// 获取注解上真实的value值

Collection<String> cacheNames = generateValue(annotatedCacheNames);

// 获取注解上的key属性值

Class<?> targetClass = getTargetClass(targetBean);

Collection<? extends Cache> caches = getCache(cacheNames);

Object key = generateKey(caches, cacheKey, targetMethod, arguments,

targetBean, targetClass,

CacheOperationExpressionEvaluator.NO_RESULT);

// 新建一个代理对象（记录了缓存注解的方法类信息）

final CachedInvocation invocation = new CachedInvocation(key, targetBean,

targetMethod, arguments);

for (final String cacheName : cacheNames) {

if (!cacheToInvocationsMap.containsKey(cacheName)) {

cacheToInvocationsMap.put(cacheName, new CopyOnWriteArraySet<>());

}

cacheToInvocationsMap.get(cacheName).add(invocation);

}}

@Override

public void refreshCache(String cacheName) {

this.refreshCacheByKey(cacheName, null);

}

// 刷新特定key缓存

@Override

public void refreshCacheByKey(String cacheName, String cacheKey) {

// 如果根据缓存名称没有找到代理信息类的set集合就不执行刷新操作。

// 只有等缓存有效时间过了，再走到切面哪里然后把代理方法信息注册到这里来。

if (!CollectionUtils.isEmpty(cacheToInvocationsMap.get(cacheName))) {

for (final CachedInvocation invocation :

cacheToInvocationsMap.get(cacheName)) {

if (!StringUtils.isBlank(cacheKey) &&

invocation.getKey().toString().equals(cacheKey)) {

logger.info("缓存：{}-{}，重新加载数据", cacheName,

cacheKey.getBytes());

refreshCache(invocation, cacheName);

}

现在刷新缓存和注册缓存执行方法的信息都有了，我们怎么来把这个执行方法信息注册到容器里面呢？

这里还少了触发点。

所以我们还需要一个切面，当执行@Cacheable注解获取缓存信息的时候我们还需要注册执行方法的信

息，所以我们写了一个切面：

/**

* 缓存拦截，用于注册方法信息

* @author yuhao.wang

@Aspect

@Component

public class CachingAnnotationsAspect {

private static final Logger logger =

LoggerFactory.getLogger(CachingAnnotationsAspect.class);

@Autowired

private InvocationRegistry cacheRefreshSupport;

private <T extends Annotation> List<T> getMethodAnnotations(AnnotatedElement

ae, Class<T> annotationType) {

List<T> anns = new ArrayList<T>(2);

// look for raw annotation

T ann = ae.getAnnotation(annotationType);

if (ann != null) {

anns.add(ann);

}

// look for meta-annotations

for (Annotation metaAnn : ae.getAnnotations()) {ann = metaAnn.annotationType().getAnnotation(annotationType);

if (ann != null) {

anns.add(ann);

}

return (anns.isEmpty() ? null : anns);

}

private Method getSpecificmethod(ProceedingJoinPoint pjp) {

MethodSignature methodSignature = (MethodSignature) pjp.getSignature();

Method method = methodSignature.getMethod();

// The method may be on an interface, but we need attributes from the

// target class. If the target class is null, the method will be

// unchanged.

Class<?> targetClass =

AopProxyUtils.ultimateTargetClass(pjp.getTarget());

if (targetClass == null && pjp.getTarget() != null) {

targetClass = pjp.getTarget().getClass();

}

Method specificMethod = ClassUtils.getMostSpecificMethod(method,

targetClass);

// If we are dealing with method with generic parameters, find the

// original method.

specificMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);

return specificMethod;

}

@Pointcut("@annotation(org.springframework.cache.annotation.Cacheable)")

public void pointcut() {

}

@Around("pointcut()")

public Object registerInvocation(ProceedingJoinPoint joinPoint) throws

Throwable {

Method method = this.getSpecificmethod(joinPoint);

List<Cacheable> annotations = this.getMethodAnnotations(method,

Cacheable.class);

Set<String> cacheSet = new HashSet<String>();

String cacheKey = null;

for (Cacheable cacheables : annotations) {

cacheSet.addAll(Arrays.asList(cacheables.value()));

cacheKey = cacheables.key();

}

cacheRefreshSupport.registerInvocation(joinPoint.getTarget(), method,

joinPoint.getArgs(), cacheSet, cacheKey);

return joinPoint.proceed();

}

注意：一个缓存名称（@Cacheable的value属性），也只能配置一个过期时间，如果配置多个以第一

次配置的为准。至此我们就把完整的设置过期时间和刷新缓存都实现了，当然还可能存在一定问题，希望大家多多指

教。

使用这种方式有个不好的地方，我们破坏了Spring Cache的结构，导致我们切换Cache的方式的时候要

改代码，有很大的依赖性。

下一篇我将对 redisCacheManager.setExpires()方法进行扩展来实现过期时间和自动刷新，进而不会去

破坏Spring Cache的原有结构，切换缓存就不会有问题了。

hibernate和ibatis的区别

Ibatis与Hibernate的区别

一、 hibernate与ibatis之间的比较：

hibernate 是当前最流行的o/r mapping框架，它出身于sf.NET，现在已经成为jboss的一部分了。

ibatis 是另外一种优秀的o/r mapping框架，目前属于apache的一个子项目了。

相对hibernate“o/r”而言，ibatis是一种“sql mapping”的orm实现。

hibernate对数据库结构提供了较为完整的封装，hibernate的o/r mapping实现了pojo 和数据库表之间

的映射，以及sql 的自动生成和执行。程序员往往只需定义好了pojo 到数据库表的映射关系，即可通过

hibernate 提供的方法完成持久层操作。程序员甚至不需要对sql 的熟练掌握， hibernate/ojb 会根据制

定的存储逻辑，自动生成对应的sql 并调用jdbc 接口加以执行。

而ibatis 的着力点，则在于pojo 与sql之间的映射关系。也就是说，ibatis并不会为程序员在运行期自动

生成sql 执行。具体的sql 需要程序员编写，然后通过映射配置文件，将sql所需的参数，以及返回的结果

字段映射到指定pojo。

使用ibatis 提供的orm机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象。

这一层与通过hibernate 实现orm 而言基本一致，而对于具体的数据操作，hibernate会自动生成sql 语

句，而ibatis 则要求开发者编写具体的sql 语句。相对hibernate而言，ibatis 以sql开发的工作量和数据

库移植性上的让步，为系统设计提供了更大的自由空间。

二、hibernate与ibatis两者的对比：

1．ibatis非常简单易学，hibernate相对较复杂，门槛较高。

2．二者都是比较优秀的开源产品

3．当系统属于二次开发,无法对数据库结构做到控制和修改,那ibatis的灵活性将比hibernate更适合

4．系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的sql语句

（或存储过程）才能达到系统性能设计指标。在这种情况下ibatis会有更好的可控性和表现。

5．ibatis需要手写sql语句，也可以生成一部分，hibernate则基本上可以自动生成，偶尔会写一些

hql。同样的需求,ibatis的工作量比hibernate要大很多。类似的，如果涉及到数据库字段的修改，

hibernate修改的地方很少，而ibatis要把那些sql mapping的地方一一修改。

6．以数据库字段一一对应映射得到的po和hibernte这种对象化映射得到的po是截然不同的，本质区

别在于这种po是扁平化的，不像hibernate映射的po是可以表达立体的对象继承，聚合等等关系的，这

将会直接影响到你的整个软件系统的设计思路。

7．hibernate现在已经是主流o/r mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都

要强于ibatis三、iBatis与Hibernate区别？

1． iBatis 需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些

Hql。同样的需求,iBATIS的工作量比 Hibernate要大很多。类似的，如果涉及到数据库字段的修改，

Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。

2. iBatis 可以进行细粒度的优化

比如说我有一个表，这个表有几个或者几十个字段，我需要更新其中的一个字段，iBatis 很简单，执行

一个sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的话就比

较麻烦了,缺省的情况下 hibernate 会更新所有字段。当然我记得 hibernate 有一个选项可以控制只保存

修改过的字段，但是我不太确定这个功能的负面效果。

例如：我需要列出一个表的部分内容，用 iBatis 的时候，这里面的好处是可以少从数据库读很多数据，

节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …一般情况下Hibernate

会把所有的字段都选出来。比如说有一个上面表有8个字段，其中有一两个比较大的字段，

varchar(255)/text。上面的场景中我为什么要把他们也选出来呢？用hibernate 的话，你又不能把这两

个不需要的字段设置为lazy load，因为还有很多地方需要一次把整个 domain object 加载出来。这个时

候就能显现出ibatis 的好处了。如果我需要更新一条记录（一个对象），如果使用 hibernate，需要现把

对象 select 出来，然后再做 update。这对数据库来说就是两条sql。而iBatis只需要一条update的sql就

可以了。减少一次与数据库的交互，对于性能的提升是非常重要。

3. 开发方面：

开发效率上，我觉得两者应该差不多。可维护性方面，我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保

存到单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保sql/hql。相对Hibernate“O/R”

而言，iBATIS 是一种“Sql Mapping”的ORM实现。而iBATIS 的着力点，则在于POJO 与SQL之间的映射

关系。也就是说，iBATIS并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然

后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。使用iBATIS 提供的

ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM

而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL 语句，而iBATIS 则要求开发者编写

具体的SQL 语句。相对Hibernate而言，iBATIS 以SQL开发的工作量和数据库移植性上的让步，为系统

设计提供了更大的自由空间。

4. 运行效率：在不考虑 cache 的情况下，iBatis 应该会比hibernate 快一些或者很多。

四、选择Hibernate还是iBATIS都有它的道理：

（

1）、Hibernate功能强大，数据库无关性好，O/R映射能力强，如果你对Hibernate相当精通，而且

对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发

速度很快，非常爽。

Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间

如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行。

（

2）、iBATiS入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使

用经验，对于没有那么高的对象模型要求的项目来说，相当完美。

iBATIS的缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库

查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。

建议：如果你的团队没有Hibernate高手，那么请用iBATIS。要把Hibernate用好，并不容易；否则你应

该选择Hibernate，这样的话你的开发速度和代码简洁性都非常棒。

讲讲mybatis的连接池。Mybatis数据源与连接池

对于ORM框架而言，数据源的组织是一个非常重要的一部分，这直接影响到框架的性能问题。本文将通

过对MyBatis框架的数据源结构进行详尽的分析，并且深入解析MyBatis的连接池。

本文首先会讲述MyBatis的数据源的分类，然后会介绍数据源是如何加载和使用的。紧接着将分类介绍

UNPOOLED、POOLED和JNDI类型的数据源组织；期间我们会重点讲解POOLED类型的数据源和其实现

的连接池原理。

一、MyBatis数据源DataSource分类

MyBatis数据源实现是在以下四个包中：

MyBatis把数据源DataSource分为三种：

ž UNPOOLED 不使用连接池的数据源

ž POOLED 使用连接池的数据源

ž JNDI 使用JNDI实现的数据源

即：

相应地，MyBatis内部分别定义了实现了java.sql.DataSource接口的UnpooledDataSource，

PooledDataSource类来表示UNPOOLED、POOLED类型的数据源。

org.apache.ibatis.datasource

org.apache.ibatis.datasource.jndi

org.apache.ibatis.datasource.pooled

org.apache.ibatis.datasource.unpooled对于JNDI类型的数据源DataSource，则是通过JNDI上下文中取值。

二、数据源DataSource的创建过程

MyBatis*数据源**DataSource**对象的创建发生在**MyBatis**初始化的过程中。*下面让我们

一步步地了解MyBatis是如何创建数据源DataSource的。

在mybatis的XML配置文件中，使用元素来配置数据源：

1. MyBatis在初始化时，解析此文件，根据的type属性来创建相应类型的的数据源

DataSource，即：

type=”POOLED” ：MyBatis会创建PooledDataSource实例

type=”UNPOOLED” ：MyBatis会创建UnpooledDataSource实例

type=”JNDI” ：MyBatis会从JNDI服务上查找DataSource实例，然后返回使用

2. 顺便说一下，MyBatis是通过工厂模式来创建数据源DataSource对象的，MyBatis定义了抽

象的工厂接口:org.apache.ibatis.datasource.DataSourceFactory,通过其getDataSource()

方法返回数据源DataSource：

定义如下：

上述三种不同类型的type，则有对应的以下dataSource工厂：

POOLED PooledDataSourceFactory

UNPOOLED UnpooledDataSourceFactory

JNDI JndiDataSourceFactory

public interface DataSourceFactory {

void setProperties(Properties props);

//生产DataSource

DataSource getDataSource();

}其类图如下所示：

3. MyBatis创建了DataSource实例后，会将其放到Configuration对象内的Environment对象

中，供以后使用。

三、 DataSource什么时候创建Connection对象

当我们需要创建SqlSession对象并需要执行SQL语句时，这时候MyBatis才会去调用dataSource对

象来创建java.sql.Connection对象。也就是说，java.sql.Connection对象的创建一直延迟到执行

SQL语句的时候。

比如，我们有如下方法执行一个简单的SQL语句：

前4句都不会导致java.sql.Connection对象的创建，只有当第5句sqlSession.selectList("SELECT *

FROM STUDENTS")，才会触发MyBatis在底层执行下面这个方法来创建java.sql.Connection对

象：

而对于DataSource的UNPOOLED的类型的实现-UnpooledDataSource是怎样实现

getConnection()方法的呢？请看下一节。

四、不使用连接池的UnpooledDataSource

当的type属性被配置成了”UNPOOLED”，MyBatis首先会实例化一个

UnpooledDataSourceFactory工厂实例，然后通过.getDataSource()方法返回一个

UnpooledDataSource实例对象引用，我们假定为dataSource。

使用UnpooledDataSource的getConnection(),每调用一次就会产生一个新的Connection实例对

象。

UnPooledDataSource的getConnection()方法实现如下：

String resource = "mybatis-config.xml";

InputStream inputStream = Resources.getResourceAsStream(resource);

SqlSessionFactory sqlSessionFactory = new

SqlSessionFactoryBuilder().build(inputStream);

SqlSession sqlSession = sqlSessionFactory.openSession();

sqlSession.selectList("SELECT * FROM STUDENTS");

protected void openConnection() throws SQLException {

if (log.isDebugEnabled()) {

log.debug("Opening JDBC Connection");

}

connection = dataSource.getConnection();

if (level != null) {

connection.setTransactionIsolation(level.getLevel());

}

setDesiredAutoCommit(autoCommmit);

}/*

UnpooledDataSource的getConnection()实现

public Connection getConnection() throws SQLException

{

return doGetConnection(username, password);

}

private Connection doGetConnection(String username, String password) throws

SQLException

{

//封装username和password成properties

Properties props = new Properties();

if (driverProperties != null)

{

props.putAll(driverProperties);

}

if (username != null)

{

props.setProperty("user", username);

}

if (password != null)

{

props.setProperty("password", password);

}

return doGetConnection(props);

}

* 获取数据连接

private Connection doGetConnection(Properties properties) throws

SQLException

{

//1.初始化驱动

initializeDriver();

//2.从DriverManager中获取连接，获取新的Connection对象

Connection connection = DriverManager.getConnection(url, properties);

//3.配置connection属性

configureConnection(connection);

return connection;

}

如上代码所示，UnpooledDataSource会做以下事情：

1. 初始化驱动：判断driver驱动是否已经加载到内存中，如果还没有加载，则会动态地加载

driver类，并实例化一个Driver对象，使用DriverManager.registerDriver()方法将其注册到

内存中，以供后续使用。

2. 创建Connection对象：使用DriverManager.getConnection()方法创建连接。

3. 配置Connection对象：设置是否自动提交autoCommit和隔离级别isolationLevel。

4. 返回Connection对象。上述的序列图如下所示：

总结：从上述的代码中可以看到，*我们每调用一次**getConnection()**方法，都会通过

**DriverManager.getConnection()**返回新的**java.sql.Connection**实例。*

五、为什么要使用连接池？

1. 创建一个java.sql.Connection实例对象的代价

首先让我们来看一下创建一个java.sql.Connection对象的资源消耗。我们通过连接Oracle数据

库，创建创建Connection对象，来看创建一个Connection对象、执行SQL语句各消耗多长时间。

代码如下：

上述程序在我笔记本上的执行结果为：

public static void main(String[] args) throws Exception

{

String sql = "select * from hr.employees where employee_id < ? and

employee_id >= ?";

PreparedStatement st = null;

ResultSet rs = null;

long beforeTimeOffset = -1L; //创建Connection对象前时间

long afterTimeOffset = -1L; //创建Connection对象后时间

long executeTimeOffset = -1L; //创建Connection对象后时间

Connection con = null;

Class.forName("oracle.jdbc.driver.OracleDriver");

beforeTimeOffset = new Date().getTime();

System.out.println("before:\t" + beforeTimeOffset);

con = DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:xe",

"louluan", "123456");

afterTimeOffset = new Date().getTime();

System.out.println("after:\t\t" + afterTimeOffset);

System.out.println("Create Costs:\t\t" + (afterTimeOffset -

beforeTimeOffset) + " ms");

st = con.prepareStatement(sql);

//设置参数

st.setInt(1, 101);

st.setInt(2, 0);

//查询，得出结果集

rs = st.executeQuery();

executeTimeOffset = new Date().getTime();

System.out.println("Exec Costs:\t\t" + (executeTimeOffset - afterTimeOffset)

+ " ms");

}从此结果可以清楚地看出，创建一个Connection对象，用了250 毫秒；而执行SQL的时间用了170

毫秒。

创建一个Connection对象用了250毫秒！这个时间对计算机来说可以说是一个非常奢侈的！

这仅仅是一个Connection对象就有这么大的代价，设想一下另外一种情况：如果我们在Web应用

程序中，为用户的每一个请求就操作一次数据库，当有10000个在线用户并发操作的话，对计算机

而言，仅仅创建Connection对象不包括做业务的时间就要损耗10000×250ms= 250 0000 ms =

2500 s = 41.6667 min,竟然要*41*分钟！！！如果对高用户群体使用这样的系统，简直就是开玩

笑！

2. 问题分析：

创建一个java.sql.Connection对象的代价是如此巨大，是因为创建一个Connection对象的过程，

在底层就相当于和数据库建立的通信连接，在建立通信连接的过程，消耗了这么多的时间，而往往

我们建立连接后（即创建Connection对象后），就执行一个简单的SQL语句，然后就要抛弃掉，

这是一个非常大的资源浪费！

3.解决方案:

对于需要频繁地跟数据库交互的应用程序，可以在创建了Connection对象，并操作完数据库后，

可以不释放掉资源，而是将它放到内存中，当下次需要操作数据库时，可以直接从内存中取出

Connection对象，不需要再创建了，这样就极大地节省了创建Connection对象的资源消耗。由于

内存也是有限和宝贵的，这又对我们对内存中的Connection对象怎么有效地维护提出了很高的要

求。我们将在内存中存放Connection对象的容器称之为连接池（Connection Pool）。下面让我

们来看一下MyBatis的线程池是怎样实现的。

六、使用了连接池的PooledDataSource

同样地，我们也是使用PooledDataSource的getConnection()方法来返回Connection对象。现在

让我们看一下它的基本原理：

PooledDataSource将java.sql.Connection对象包裹成PooledConnection对象放到了PoolState类

型的容器中维护。 MyBatis将连接池中的PooledConnection分为两种状态：空闲状态（idle）和

活动状态(active)，这两种状态的PooledConnection对象分别被存储到PoolState容器内的

idleConnections和activeConnections两个List集合中：

idleConnections:空闲(idle)状态PooledConnection对象被放置到此集合中，表示当前闲置的没

有被使用的PooledConnection集合，调用PooledDataSource的getConnection()方法时，会优先

从此集合中取PooledConnection对象。当用完一个java.sql.Connection对象时，MyBatis会将其

包裹成PooledConnection对象放到此集合中。

activeConnections:活动(active)状态的PooledConnection对象被放置到名为activeConnections

的ArrayList中，表示当前正在被使用的PooledConnection集合，调用PooledDataSource的

getConnection()方法时，会优先从idleConnections集合中取PooledConnection对象,如果没有，

则看此集合是否已满，如果未满，PooledDataSource会创建出一个PooledConnection，添加到此集合中，并返回。

PoolState连接池的大致结构如下所示：

6.1 获取java.sql.Connection对象的过程

下面让我们看一下PooledDataSource 的getConnection()方法获取Connection对象的实现：

public Connection getConnection() throws SQLException {

return popConnection(dataSource.getUsername(),

dataSource.getPassword()).getProxyConnection();

}

public Connection getConnection(String username, String password) throws

SQLException {

return popConnection(username, password).getProxyConnection();

}

上述的popConnection()方法，会从连接池中返回一个可用的PooledConnection对象，然后再调

用getProxyConnection()方法最终返回Conection对象。（至于为什么会有getProxyConnection(),

请关注下一节）

现在让我们看一下popConnection()方法到底做了什么：

1. 先看是否有空闲(idle)状态下的PooledConnection对象，如果有，就直接返回一个可用的

PooledConnection对象；否则进行第2步。

2. 查看活动状态的PooledConnection池activeConnections是否已满；如果没有满，则创建一

个新的PooledConnection对象，然后放到activeConnections池中，然后返回此

PooledConnection对象；否则进行第三步；

3. 看最先进入activeConnections池中的PooledConnection对象是否已经过期：如果已经过

期，从activeConnections池中移除此对象，然后创建一个新的PooledConnection对象，添

加到activeConnections中，然后将此对象返回；否则进行第4步。4. 线程等待，循环2步

* 传递一个用户名和密码，从连接池中返回可用的PooledConnection

private PooledConnection popConnection(String username, String password)

throws SQLException

{

boolean countedWait = false;

PooledConnection conn = null;

long t = System.currentTimeMillis();

int localBadConnectionCount = 0;

while (conn == null)

{

synchronized (state)

{

if (state.idleConnections.size() > 0)

{

// 连接池中有空闲连接，取出第一个

conn = state.idleConnections.remove(0);

if (log.isDebugEnabled())

{

log.debug("Checked out connection " +

conn.getRealHashCode() + " from pool.");

}

else

{

// 连接池中没有空闲连接，则取当前正在使用的连接数小于最大限定值，

if (state.activeConnections.size() <

poolMaximumActiveConnections)

{

// 创建一个新的connection对象

conn = new PooledConnection(dataSource.getConnection(),

this);

@SuppressWarnings("unused")

//used in logging, if enabled

Connection realConn = conn.getRealConnection();

if (log.isDebugEnabled())

{

log.debug("Created connection " +

conn.getRealHashCode() + ".");

}

else

{

// Cannot create new connection 当活动连接池已满，不能创建

时，取出活动连接池的第一个，即最先进入连接池的PooledConnection对象

// 计算它的校验时间，如果校验时间大于连接池规定的最大校验时间，则认

为它已经过期了，利用这个PoolConnection内部的realConnection重新生成一个

PooledConnection

PooledConnection oldestActiveConnection =

state.activeConnections.get(0);

long longestCheckoutTime =

oldestActiveConnection.getCheckoutTime();if (longestCheckoutTime > poolMaximumCheckoutTime)

{

// Can claim overdue connection

state.claimedOverdueConnectionCount++;

state.accumulatedCheckoutTimeOfOverdueConnections +=

longestCheckoutTime;

state.accumulatedCheckoutTime +=

longestCheckoutTime;

state.activeConnections.remove(oldestActiveConnection);

(!oldestActiveConnection.getRealConnection().getAutoCommit())

{

oldestActiveConnection.getRealConnection().rollback();

}

conn = new

PooledConnection(oldestActiveConnection.getRealConnection(), this);

oldestActiveConnection.invalidate();

if (log.isDebugEnabled())

{

log.debug("Claimed overdue connection " +

conn.getRealHashCode() + ".");

}

else

{

//如果不能释放，则必须等待有

// Must wait

try

{

if (!countedWait)

{

state.hadToWaitCount++;

countedWait = true;

}

if (log.isDebugEnabled())

{

log.debug("Waiting as long as " +

poolTimeToWait + " milliseconds for connection.");

}

long wt = System.currentTimeMillis();

state.wait(poolTimeToWait);

state.accumulatedWaitTime +=

System.currentTimeMillis() - wt;

}

catch (InterruptedException e)

{

break;

}

//如果获取PooledConnection成功，则更新其信息

if (conn != null){

if (conn.isValid())

{

if (!conn.getRealConnection().getAutoCommit())

{

conn.getRealConnection().rollback();

}

conn.setConnectionTypeCode(assembleConnectionTypeCode(dataSource.getUrl(),

username, password));

conn.setCheckoutTimestamp(System.currentTimeMillis());

conn.setLastUsedTimestamp(System.currentTimeMillis());

state.activeConnections.add(conn);

state.requestCount++;

state.accumulatedRequestTime +=

System.currentTimeMillis() - t;

}

else

{

if (log.isDebugEnabled())

{

log.debug("A bad connection (" +

conn.getRealHashCode() + ") was returned from the pool, getting another

connection.");

}

state.badConnectionCount++;

localBadConnectionCount++;

conn = null;

if (localBadConnectionCount >

(poolMaximumIdleConnections + 3))

{

if (log.isDebugEnabled())

{

log.debug("PooledDataSource: Could not get a

good connection to the database.");

}

throw new SQLException("PooledDataSource: Could not

get a good connection to the database.");

}

if (conn == null)

{

if (log.isDebugEnabled())

{

log.debug("PooledDataSource: Unknown severe error condition.

The connection pool returned a null connection.");

}

throw new SQLException("PooledDataSource: Unknown severe error

condition. The connection pool returned a null connection.");

}

return conn;

}对应的处理流程图如下所示：

如上所示,对于PooledDataSource的getConnection()方法内，先是调用类PooledDataSource的

popConnection()方法返回了一个PooledConnection对象，然后调用了PooledConnection的

getProxyConnection()来返回Connection对象。

6.2java.sql.Connection对象的回收

**当我们的程序中使用完Connection对象时，如果不使用数据库连接池，我们一般会调用

connection.close()方法，关闭connection连接，释放资源。如下所示：**

private void test() throws ClassNotFoundException, SQLException

{

String sql = "select * from hr.employees where employee_id < ? and

employee_id >= ?";

PreparedStatement st = null;

ResultSet rs = null;

Connection con = null;

Class.forName("oracle.jdbc.driver.OracleDriver");

try

{

con =

DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:xe",

"louluan", "123456");

st = con.prepareStatement(sql);

//设置参数

st.setInt(1, 101);

st.setInt(2, 0);

//查询，得出结果集

rs = st.executeQuery();

//取数据，省略

//关闭，释放资源

con.close();

}

catch (SQLException e)

{

con.close();

e.printStackTrace();

}

调用过close()方法的Connection对象所持有的资源会被全部释放掉，Connection对象也就不能

再使用。

那么，如果我们使用了连接池，我们在用完了Connection对象时，需要将它放在连接池中，该怎

样做呢？可能大家第一个在脑海里闪现出来的想法就是：我在应该调用con.close()方法的时候，不调用

close()f方法，将其换成将Connection对象放到连接池容器中的代码！

好，我们将上述的想法实现，首先定义一个简易连接池Pool，然后将上面的代码改写：

package com.foo.jdbc;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.SQLException;

import java.util.Vector;

/**

* 一个线程安全的简易连接池实现，此连接池是单例的

* putConnection()将Connection添加到连接池中

* getConnection()返回一个Connection对象

public class Pool {

private static Vector<Connection> pool = new Vector<Connection>();

private static int MAX_CONNECTION =100;

private static String DRIVER="oracle.jdbc.driver.OracleDriver";

private static String URL = "jdbc:oracle:thin:@127.0.0.1:1521:xe";

private static String USERNAME = "louluan";

private static String PASSWROD = "123456";

static {

try {

Class.forName(DRIVER);

} catch (ClassNotFoundException e) {

e.printStackTrace();

}

/**

* 将一个Connection对象放置到连接池中

public static void putConnection(Connection connection){

synchronized(pool)

{

if(pool.size()<MAX_CONNECTION)

{

pool.add(connection);

}

/**

* 返回一个Connection对象，如果连接池内有元素，则pop出第一个元素；

* 如果连接池Pool中没有元素，则创建一个connection对象，然后添加到pool中

* @return Connection*/

public static Connection getConnection(){

Connection connection = null;

synchronized(pool)

{

if(pool.size()>0)

{

connection = pool.get(0);

pool.remove(0);

}

else

{

connection = createConnection();

pool.add(connection);

}

return connection;

}

/**

* 创建一个新的Connection对象

private static Connection createConnection()

{

Connection connection = null;

try {

connection = DriverManager.getConnection(URL,

USERNAME,PASSWROD);

} catch (SQLException e) {

e.printStackTrace();

}

return connection;

}

package com.foo.jdbc;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.util.Vector;

public class PoolTest

{

private void test() throws ClassNotFoundException, SQLException

{

String sql = "select * from hr.employees where employee_id < ? and

employee_id >= ?";

PreparedStatement st = null;

ResultSet rs = null;

Connection con = null;

Class.forName("oracle.jdbc.driver.OracleDriver");

try

{con =

DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:xe",

"louluan", "123456");

st = con.prepareStatement(sql);

//设置参数

st.setInt(1, 101);

st.setInt(2, 0);

//查询，得出结果集

rs = st.executeQuery();

//取数据，省略

//将不再使用的Connection对象放到连接池中，供以后使用

Pool.putConnection(con);

}

catch (SQLException e)

{

e.printStackTrace();

}

上述的代码就是将我们使用过的Connection对象放到Pool连接池中，我们需要Connection对象的

话，只需要使用Pool.getConnection()方法从里面取即可。

是的,上述的代码完全可以实现此能力，不过有一个很不优雅的实现：就是我们需要手动地将

Connection对象放到Pool连接池中，这是一个很傻的实现方式。这也和一般使用Connection对

象的方式不一样：一般使用Connection的方式是使用完后，然后调用.close()方法释放资源。

为了和一般的使用Conneciton对象的方式保持一致，我们希望当Connection使用完后，调

用.close()方法，而实际上Connection资源并没有被释放，而实际上被添加到了连接池中。这样可

以做到吗？答案是可以。上述的要求从另外一个角度来描述就是：能否提供一种机制，让我们知道

Connection对象调用了什么方法，从而根据不同的方法自定义相应的处理机制。恰好代理机制就

可以完成上述要求.

怎样实现Connection对象调用了close()方法，而实际是将其添加到连接池中

这是要使用代理模式，为真正的Connection对象创建一个代理对象，代理对象所有的方法都是调

用相应的真正Connection对象的方法实现。当代理对象执行close()方法时，要特殊处理，不调用

真正Connection对象的close()方法，而是将Connection对象添加到连接池中。

MyBatis的PooledDataSource的PoolState内部维护的对象是PooledConnection类型的对象，而

PooledConnection则是对真正的数据库连接java.sql.Connection实例对象的包裹器。

PooledConnection对象内持有一个真正的数据库连接java.sql.Connection实例对象和一个

java.sql.Connection的代理：

其部分定义如下：class PooledConnection implements InvocationHandler {

//......

//所创建它的datasource引用

private PooledDataSource dataSource;

//真正的Connection对象

private Connection realConnection;

//代理自己的代理Connection

private Connection proxyConnection;

//......

}

PooledConenction

实现了

InvocationHandler

接口，并且，

proxyConnection

对象也是根据这个它来生成的代理对象：

public PooledConnection(Connection connection, PooledDataSource dataSource)

{

this.hashCode = connection.hashCode();

this.realConnection = connection;

this.dataSource = dataSource;

this.createdTimestamp = System.currentTimeMillis();

this.lastUsedTimestamp = System.currentTimeMillis();

this.valid = true;

this.proxyConnection = (Connection)

Proxy.newProxyInstance(Connection.class.getClassLoader(), IFACES, this);

}

实际上，我们调用PooledDataSource的getConnection()方法返回的就是这个proxyConnection对

象。

当我们调用此proxyConnection对象上的任何方法时，都会调用PooledConnection对象内

invoke()方法。

让我们看一下PooledConnection类中的invoke()方法定义：

public Object invoke(Object proxy, Method method, Object[] args) throws

Throwable {

String methodName = method.getName();

//当调用关闭的时候，回收此Connection到PooledDataSource中

if (CLOSE.hashCode() == methodName.hashCode() &&

CLOSE.equals(methodName)) {

dataSource.pushConnection(this);

return null;

} else {从上述代码可以看到，当我们使用了pooledDataSource.getConnection()返回的Connection对象

的close()方法时，不会调用真正Connection的close()方法，而是将此Connection对象放到连接池

中。

七、JNDI类型的数据源DataSource

对于JNDI类型的数据源DataSource的获取就比较简单，MyBatis定义了一个

JndiDataSourceFactory工厂来创建通过JNDI形式生成的DataSource。

下面让我们看一下JndiDataSourceFactory的关键代码：

经典面试题

问题一

什么是 Spring Boot？

多年来，随着新功能的增加，spring 变得越来越复杂。只需访问 https://spring.io/projects

try {

if (!Object.class.equals(method.getDeclaringClass())) {

checkConnection();

}

return method.invoke(realConnection, args);

} catch (Throwable t) {

throw ExceptionUtil.unwrapThrowable(t);

}

if (properties.containsKey(INITIAL_CONTEXT)

&& properties.containsKey(DATA_SOURCE))

{

//从JNDI上下文中找到DataSource并返回

Context ctx = (Context)

initCtx.lookup(properties.getProperty(INITIAL_CONTEXT));

dataSource = (DataSource) ctx.lookup(properties.getProperty(DATA_SOURCE));

}

else if (properties.containsKey(DATA_SOURCE))

{

// //从JNDI上下文中找到DataSource并返回

dataSource = (DataSource)

initCtx.lookup(properties.getProperty(DATA_SOURCE));

}页面，我们就会看到可以在我们的应用程序中使用的所有 Spring 项目的不同功能。如果必须启动一个新

的 Spring 项目，我们必须添加构建路径或添加 Maven 依赖关系，配置应用程序服务器，添加 spring 配

置。因此，开始一个新的 spring 项目需要很多努力，因为我们现在必须从头开始做所有事情。

Spring Boot 是解决这个问题的方法。Spring Boot 已经建立在现有 spring 框架之上。使用 spring

启动，我们避免了之前我们必须做的所有样板代码和配置。因此，Spring Boot 可以帮助我们以最少的

工作量，更加健壮地使用现有的 Spring 功能。

问题二

Spring Boot 有哪些优点？

Spring Boot 的优点有：

减少开发，测试时间和努力。

使用 JavaConfig 有助于避免使用 XML。

避免大量的 Maven 导入和各种版本冲突。

提供意见发展方法。

通过提供默认值快速开始开发。

没有单独的 Web 服务器需要。这意味着你不再需要启动 Tomcat，Glassfish 或其他任何东西。

需要更少的配置因为没有 web.xml 文件。只需添加用@ Configuration 注释的类，然后添加用@Bean

注释的方法，Spring 将自动加载对象并像以前一样对其进行管理。您甚至可以将

@Autowired 添加到 bean 方法中，以使 Spring 自动装入需要的依赖关系中。

基于环境的配置使用这些属性，您可以将您正在使用的环境传递到应用程序：Dspring.profiles.active =

{enviornment}。在加载主应用程序属性文件后，Spring 将在

（application{environment} .properties）中加载后续的应用程序属性文件。

问题三

什么是 JavaConfig？

Spring JavaConfig 是 Spring 社区的产品，它提供了配置 Spring IoC 容器的纯 Java 方法。因此有助于

避免使用 XML 配置。使用 JavaConfig 的优点在于：

面向对象的配置。由于配置被定义为 JavaConfig 中的类，因此用户可以充分利用 Java 中的面向对象功

能。一个配置类可以继承另一个，重写它的@Bean 方法等。

减少或消除 XML 配置。基于依赖注入原则的外化配置的好处已被证明。但是，许多开发人员不希望在

XML 和 Java 之间来回切换。JavaConfig 为开发人员提供了一种纯 Java 方法来配置与 XML 配置概念相

似的 Spring 容器。从技术角度来讲，只使用 JavaConfig 配置类来配置容器是可行的，但实际上很多人

认为将 JavaConfig 与 XML 混合匹配是理想的。

类型安全和重构友好。JavaConfig 提供了一种类型安全的方法来配置 Spring 容器。由于

Java 5.0 对泛型的支持，现在可以按类型而不是按名称检索 bean，不需要任何强制转换或基于字符串

的查找。问题四

如何重新加载 Spring Boot 上的更改，而无需重新启动服务器？

这可以使用 DEV 工具来实现。通过这种依赖关系，您可以节省任何更改，嵌入式 tomcat

将重新启动。Spring Boot 有一个开发工具（DevTools）模块，它有助于提高开发人员的生产力。Java

开发人员面临的一个主要挑战是将文件更改自动部署到服务器并自动重启服务器。开发人员可以重新加

载 Spring Boot 上的更改，而无需重新启动服务器。这将消除每次手动部署更改的需要。Spring Boot

在发布它的第一个版本时没有这个功能。这是开发人员最需要的功能。DevTools 模块完全满足开发人员

的需求。该模块将在生产环境中被禁用。

它还提供 H2 数据库控制台以更好地测试应用程序。

org.springframework.boot spring-boot-devtools true

问题五

Spring Boot 中的监视器是什么？

Spring boot actuator 是 spring 启动框架中的重要功能之一。Spring boot 监视器可帮助您访问生产环

境中正在运行的应用程序的当前状态。有几个指标必须在生产环境中进行检查和监控。即使一些外部应

用程序可能正在使用这些服务来向相关人员触发警报消息。监视器模块公开了一组可直接作为 HTTP

URL 访问的 REST 端点来检查状态。

问题六

如何在 Spring Boot 中禁用 Actuator 端点安全性？

默认情况下，所有敏感的 HTTP 端点都是安全的，只有具有 ACTUATOR 角色的用户才能访

问它们。安全性是使用标准的 HttpServletRequest.isUserInRole 方法实施的。我们可以使用

management.security.enabled = false

来禁用安全性。只有在执行机构端点在防火墙后访问时，才建议禁用安全性。

问题七

如何在自定义端口上运行 Spring Boot 应用程序？

为了在自定义端口上运行 Spring Boot 应用程序，您可以在 application.properties 中指定端口。

server.port = 8090

问题八

什么是 YAML？

YAML 是一种人类可读的数据序列化语言。它通常用于配置文件。

与属性文件相比，如果我们想要在配置文件中添加复杂的属性，YAML 文件就更加结构化，而且更少混

淆。可以看出 YAML 具有分层配置数据。问题九

如何实现 Spring Boot 应用程序的安全性？

为了实现 Spring Boot 的安全性，我们使用 spring-boot-starter-security 依赖项，并且必须添加安全配

置。它只需要很少的代码。配置类将必须扩展 WebSecurityConfigurerAdapter 并覆盖其方法。

问题十

如何集成 Spring Boot 和 ActiveMQ？

对于集成 Spring Boot 和 ActiveMQ，我们使用

spring-boot-starter-activemq 依赖关系。它只需要很少的配置，并且不需要样板代码。

问题十一

如何使用 Spring Boot 实现分页和排序？

使用 Spring Boot 实现分页非常简单。使用 Spring Data-JPA 可以实现将可分页的

org.springframework.data.domain.Pageable 传递给存储库方法。

问题十二

什么是 Swagger？你用 Spring Boot 实现了它吗？

Swagger 广泛用于可视化 API，使用 Swagger UI 为前端开发人员提供在线沙箱。Swagger 是用于生成

RESTful Web 服务的可视化表示的工具，规范和完整框架实现。它使文档能够以与服务器相同的速度

更新。当通过 Swagger 正确定义时，消费者可以使用最少量的实现逻

辑来理解远程服务并与其进行交互。因此，Swagger 消除了调用服务时的猜测。

问题十三

什么是 Spring Profiles？

Spring Profiles 允许用户根据配置文件（dev，test，prod 等）来注册 bean。因此，当应用程序在开

发中运行时，只有某些 bean 可以加载，而在 PRODUCTION 中，某些其他 bean 可以加载。假设我们

的要求是 Swagger 文档仅适用于 QA 环境，并且禁用所有其他文档。这可以使用配置文件来完成。

Spring Boot 使得使用配置文件非常简单。

问题十四

什么是 Spring Batch？

Spring Boot Batch 提供可重用的函数，这些函数在处理大量记录时非常重要，包括日志/跟踪，事务管

理，作业处理统计信息，作业重新启动，跳过和资源管理。它还提供了更先进的技术服务和功能，通过

优化和分区技术，可以实现极高批量和高性能批处理作业。简单以及复杂的大批量批处理作业可以高度可扩展的方式利用框架处理重要大量的信息。

问题十五

什么是 FreeMarker 模板？

FreeMarker 是一个基于 Java 的模板引擎，最初专注于使用 MVC 软件架构进行动态网页生成。使用

Freemarker 的主要优点是表示层和业务层的完全分离。程序员可以处理应用程序代码，而设计人员可

以处理 html 页面设计。最后使用 freemarker 可以将这些结合起来，给出最终的输出页面。

问题十六

如何使用 Spring Boot 实现异常处理？

Spring 提供了一种使用 ControllerAdvice 处理异常的非常有用的方法。我们通过实现一个

ControlerAdvice 类，来处理控制器类抛出的所有异常。

问题十七

您使用了哪些 starter maven 依赖项？

使用了下面的一些依赖项

spring-boot-starter-activemq spring-boot-starter-security

spring-boot-starter-web

这有助于增加更少的依赖关系，并减少版本的冲突。

问题十八

什么是 CSRF 攻击？

CSRF 代表跨站请求伪造。这是一种攻击，迫使最终用户在当前通过身份验证的 Web 应用程序上执行不

需要的操作。CSRF 攻击专门针对状态改变请求，而不是数据窃取，因为攻击者无法查看对伪造请求的响

应。

问题十九

什么是 WebSockets？

WebSocket 是一种计算机通信协议，通过单个 TCP 连接提供全双工通信信道。

WebSocket 是双向的 -使用 WebSocket 客户端或服务器可以发起消息发送。

WebSocket 是全双工的 -客户端和服务器通信是相互独立的。

单个 TCP 连接 -初始连接使用 HTTP，然后将此连接升级到基于套接字的连接。然后这个单一连接用于所

有未来的通信

Light -与 http 相比，WebSocket 消息数据交换要轻得多。问题二十

什么是 AOP？

在软件开发过程中，跨越应用程序多个点的功能称为交叉问题。这些交叉问题与应用程序的主要业务逻

辑不同。因此，将这些横切关注与业务逻辑分开是面向方面编程（AOP）的地方。

问题二十一

什么是 Apache Kafka？

Apache Kafka 是一个分布式发布 - 订阅消息系统。它是一个可扩展的，容错的发布 - 订阅消息系统，它

使我们能够构建分布式应用程序。这是一个 Apache 顶级项目。Kafka 适合离线和在线消息消费。

问题二十二

我们如何监视所有 Spring Boot 微服务？

Spring Boot 提供监视器端点以监控各个微服务的度量。这些端点对于获取有关应用程序的信息（如它

们是否已启动）以及它们的组件（如数据库等）是否正常运行很有帮助。但是，使用监视器的一个主要

缺点或困难是，我们必须单独打开应用程序的知识点以了解其状态或健康状况。想象一下涉及 50 个应

用程序的微服务，管理员将不得不击中所有 50 个应用程序的执行终端。

Spring Cloud（一明老师，晁老师）

Spring Cloud熔断机制介绍；

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调

用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是

@HystrixCommand，Hystrix会找有这个注解的方法，并将这类方法关联到和熔断器连在一起的代理

上。当前，@HystrixCommand仅当类的注解为@Service或@Component时才会发挥作用。

Spring Cloud对比下Dubbo，什么场景下该使用Spring

Cloud？

两者所解决的问题域不一样：Dubbo的定位始终是一款RPC框架，而Spring Cloud的目的是微服务架构

下的一站式解决方案。

Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。核心要素

Dubbo

Spring Cloud

服务注册中心

Zookeeper、

Redis

Spring Cloud Netflix Eureka

服务调用方式

RPC

REST API

服务网关

无

Spring Cloud

断路器

不完善

Spring Cloud Netiflix Hystrix

分布式配置

无

Spring Cloud Config

分布式追踪系

统

无

Spring Cloud Sleuth

消息总线

无

Spring Cloud Bus

数据流

无

Spring Cloud Stream 基于Redis,Kafka实现的消息微服

务

批量任务

无

Spring Cloud Task

严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上

面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契

约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。

CAP原理和BASE理论

CAP原则(CAP定理)、BASE理论

一、CAP原则CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可

用性）、Partition tolerance（分区容错性），三者不可得兼。

CAP原则是NOSQL数据库的基石。

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：

一致性（

C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访

问同一份最新的数据副本）

可用性（

A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据

更新具备高可用性）

分区容忍性（

P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成

数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

一致性与可用性的决择编辑

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延

迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权

衡，没有NoSQL系统能同时保证这三点。

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

1. 数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求

并不高。允许实现最终一致性。

2. 数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多

web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的

订阅者才看到这条动态是完全可以接受的。

3. 对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查

询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只

是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。取舍策略

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃

P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式

系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分

区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢

失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其

实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性

是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源

来部署分布式数据库。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，

为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如

某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的

时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服

务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流

程的严重阻塞。

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致

性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布

式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong

consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性

（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价

于系统不可用，以下两个就是“基本可用”的典型例子。

响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但

由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔

订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳

定性，部分消费者可能会被引导到一个降级页面。

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在

不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状

态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强

一致性

亚马逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。

他认为最终一致性时一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终

一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够胡渠道最新的值。同时，在没有发

生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因

素。

在实际工程实践中，最终一致性存在以下五类主要变种。

因果一致性：

读己之所写：

会话一致性：

单调读一致性：

单调写一致性：

以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，

以构建一个具有最终一致性的分布式系统。事实上，可以将其中的若干个变种相互结合起来，以构建一

个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特

性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和

异步方式来实现主备数据复制技术。在同步方式中，数据的复制国耻鞥通常是更新事务的一部分，因此

在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决

于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常

因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能

够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最

新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就

是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以

看作是一种特殊的因果一致性。

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所

写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据

访问都不应该返回更旧的值。

单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。导致无法及时将事务应用到备库上，那么狠显然，从备库中读取的的数据将是旧的，因此就出现了不一

致的情况。当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一

致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它

完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内

是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致

性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在

一起使用。

小结：

计算机系统从集中式向分布式的变革随着包括分布式网络、分布式事务和分布式数据一致性等在内的一

系列问题与挑战，同时也催生了一大批诸如ACID、CAP和BASE等经典理论的快速发展。

与NoSQL的关系编辑

传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机

制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的

体现）[2] 。

传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操

作是原子性的，要么事务中的操作全部执行，要么一个都不执行;C代表一致性，即保证进行事务的过程

中整个数据加的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖

彼此数据等;D表示持久化，即事务一量完成，那么数据应该是被写到安全的，持久化存储的设备上（比

如磁盘）。

NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，

在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。

CAP的是什么关系

It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in

every system, unfortunately no system can achieve all three at the same time.

在分布式系统的设计中，没有一种设计可以同时满足一致性，可用性，分区容错性 3个特性

注意：不要将弱一致性，最终一致性放到CAP理论里混为一谈（混淆概念的坑真多）

弱一致性，最终一致性你可以认为和CAP的C一点关系也没有，因为CAP的C是更新操作完成后，任何节

点看到的数据完全一致, 弱一致性。最终一致性本身和CAP的C一致性是违背的，所以你可以看到那些谎

称自己系统同时具备CAP 3个特性是多么的可笑，可能国内更多的场景是：一个开放人员一旦走上讲台

演讲，就立马转变为了营销人员，连最基本的理念也不要了。

这里有一篇标题很大的文章 cap-twelve-years-later-how-the-rules-have-changed ，实际上本文的

changed更多的是在思考方式上，而本身CAP理论是没有changed的

为什么会是这样

我们来看一个简单的问题, 一个DB服务搭建在两个机房（北京,广州)，两个DB实例同时提供写入和读取1. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功

在没有出现网络故障的时候，满足CA原则，C 即我的任何一个写入，更新操作成功并返回客户端完

成后,分布式的所有节点在同一时间的数据完全一致， A 即我的读写操作都能够成功，但是当出现

网络故障时，我不能同时保证CA，即P条件无法满足

2. 假设DB的更新操作是只写本地机房成功就返回，通过binlog/oplog回放方式同步至侧边机房

这种操作保证了在出现网络故障时,双边机房都是可以提供服务的，且读写操作都能成功，意味着他

满足了AP ，但是它不满足C，因为更新操作返回成功后，双边机房的DB看到的数据会存在短暂不

一致，且在网络故障时，不一致的时间差会很大（仅能保证最终一致性）

3. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务

降级服务，如停止写入，只提供读取功能，这样能保证数据是一致的，且网络故障时能提供服务，

满足CP原则，但是他无法满足可用性原则

选择权衡

通过上面的例子，我们得知，我们永远无法同时得到CAP这3个特性，那么我们怎么来权衡选择呢？

选择的关键点取决于业务场景

对于大多数互联网应用来说（如网易门户），因为机器数量庞大，部署节点分散，网络故障是常态，可

用性是必须需要保证的，所以只有设置一致性来保证服务的AP，通常常见的高可用服务吹嘘5个9 6个9

服务SLA稳定性就本都是放弃C选择AP

对于需要确保强一致性的场景，如银行，通常会权衡CA和CP模型，CA模型网络故障时完全不可用，CP

模型具备部分可用性，实际的选择需要通过业务场景来权衡（并不是所有情况CP都好于CA，只能查看信

息不能更新信息有时候从产品层面还不如直接拒绝服务）

延伸

BASE(Basically Available, Soft State, Eventual Consistency 基本可用、软状态、最终一致性) 对CAP AP

理论的延伸, Redis等众多系统构建与这个理论之上

ACID 传统数据库常用的设计理念, ACID和BASE代表了两种截然相反的设计哲学，分处一致性-可用性分

布图谱的两极。

分布式系统的典型应用

分布式系统是一个非常广泛的概念，它最终要落实到解决实际问题上，不同的问题有不同的方法和架

构。所有的开源软件都是以某个应用场景出现，而纯粹以“分布式”概念进行划分的比较少见。

但如果以算法划分，到能分出几类：

1.以Leader选举为主的一类算法，比如paxos、viewstamp，就是现在zookeeper、Chuby等工具的主

体

2.以分布式事务为主的一类主要是二段提交，这些分布式数据库管理器及数据库都支持3.以若一致性为主的，主要代表是Cassandra的W、R、N可调节的一致性

4.以租赁机制为主的，主要是一些分布式锁的概念，目前还没有看到纯粹“分布式”锁的实现

5.以失败探测为主的，主要是Gossip和phi失败探测算法，当然也包括简单的心跳

6.以弱一致性、因果一致性、顺序一致性为主的，开源尚不多，但大都应用在Linkedin、Twitter、

Facebook等公司内部

7当然以异步解耦为主的，还有各类Queue

分布式事务、分布式锁

常用的分布式事务解决方案介绍有多少种？

关于分布式事务，工程领域主要讨论的是强一致性和最终一致性的解决方案。典型方案包括：

1. 两阶段提交（2PC, Two-phase Commit）方案

2. eBay 事件队列方案

3. TCC 补偿模式

4. 缓存数据最终一致性

一、一致性理论

分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性

宕机，像单机事务一样的ACID是无法奢望的。另外，业界著名的CAP理论也告诉我们，对分布式系统，

需要将数据一致性和系统可用性、分区容忍性放在天平上一起考虑。

两阶段提交协议（简称2PC）是实现分布式事务较为经典的方案，但2PC 的可扩展性很差，在分布式架

构下应用代价较大，eBay 架构师Dan Pritchett 提出了BASE 理论，用于解决大规模分布式系统下的数据

一致性问题。BASE 理论告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。

1、CAP理论

在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition

Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。一致性：分布式环境下多个节点的数据是否强一致。

可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结

果。

分区容忍性：特指对网络分区的容忍性。

举例：Cassandra、Dynamo 等，默认优先选择AP，弱化C；HBase、MongoDB 等，默认优先选择

CP，弱化A。

2、BASE 理论

核心思想：

基本可用（Basically

Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。

软状态（Soft

State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。

最终一致性（Eventual

Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。

二、一致性模型

数据的一致性模型可以分成以下 3 类：

1. 强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。

2. 弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以

读到。

3. 最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但

是保证最终会返回上一次更新操作的值。

分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW算法分析。

三、分布式事务解决方案

1、2PC方案——强一致性2PC的核心原理是通过提交分阶段和记日志的方式，记录下事务提交所处的阶段状态，在组件宕机重启

后，可通过日志恢复事务提交的阶段状态，并在这个状态节点重试，如Coordinator重启后，通过日志

可以确定提交处于Prepare还是PrepareAll状态，若是前者，说明有节点可能没有Prepare成功，或所有

节点Prepare成功但还没有下发Commit，状态恢复后给所有节点下发RollBack；若是PrepareAll状态，

需要给所有节点下发Commit，数据库节点需要保证Commit幂等。

2PC方案的问题：

1. 同步阻塞。

2. 数据不一致。

3. 单点问题。

升级的3PC方案旨在解决这些问题，主要有两个改进：

1. 增加超时机制。

2. 两阶段之间插入准备阶段。

但三阶段提交也存在一些缺陷，要彻底从协议层面避免数据不一致，可以采用Paxos或者Raft 算法。

2、eBay 事件队列方案——最终一致性

eBay 的架构师Dan Pritchett，曾在一篇解释BASE 原理的论文《Base：An Acid Alternative》中提到一

个eBay 分布式系统一致性问题的解决方案。它的核心思想是将需要分布式处理的任务通过消息或者日志

的方式来异步执行，消息或日志可以存到本地文件、数据库或消息队列，再通过业务规则进行失败重

试，它要求各服务的接口是幂等的。

描述的场景为，有用户表user 和交易表transaction，用户表存储用户信息、总销售额和总购买额，交易

表存储每一笔交易的流水号、买家信息、卖家信息和交易金额。如果产生了一笔交易，需要在交易表增

加记录，同时还要修改用户表的金额。论文中提出的解决方法是将更新交易表记录和用户表更新消息放在一个本地事务来完成，为了避免重复

消费用户表更新消息带来的问题，增加一个操作记录表updates_applied来记录已经完成的交易相关的

信息。

这个方案的核心在于第二阶段的重试和幂等执行。失败后重试，这是一种补偿机制，它是能保证系统最

终一致的关键流程。

3、TCC （Try-Confirm-Cancel）补偿模式——最终一致性

某业务模型如图，由服务 A、服务B、服务C、服务D 共同组成的一个微服务架构系统。服务A 需要依次

调用服务B、服务C 和服务D 共同完成一个操作。当服务A 调用服务D 失败时，若要保证整个系统数据的

一致性，就要对服务B 和服务C 的invoke 操作进行回滚，执行反向的revert 操作。回滚成功后，整个微

服务系统是数据一致的。实现关键要素：

1. 服务调用链必须被记录下来。

2. 每个服务提供者都需要提供一组业务逻辑相反的操作，互为补偿，同时回滚操作要保证幂等。

3. 必须按失败原因执行不同的回滚策略。

4、缓存数据最终一致性

在我们的业务系统中，缓存（Redis 或者Memcached）通常被用在数据库前面，作为数据读取的缓冲，

使得I/O 操作不至于直接落在数据库上。以商品详情页为例，假如卖家修改了商品信息，并写回到数据

库，但是这时候用户从商品详情页看到的信息还是从缓存中拿到的过时数据，这就出现了缓存系统和数

据库系统中的数据不一致的现象。

要解决该场景下缓存和数据库数据不一致的问题我们有以下两种解决方案：

1. 为缓存数据设置过期时间。当缓存中数据过期后，业务系统会从数据库中获取数据，并将新值放入

缓存。这个过期时间就是系统可以达到最终一致的容忍时间。

2. 更新数据库数据后同时清除缓存数据。数据库数据更新后，同步删除缓存中数据，使得下次对商品

详情的获取直接从数据库中获取，并同步到缓存。

四、选择建议

在面临数据一致性问题的时候，首先要从业务需求的角度出发，确定我们对于3 种一致性模型的接受程

度，再通过具体场景来决定解决方案。

从应用角度看，分布式事务的现实场景常常无法规避，在有能力给出其他解决方案前，2PC也是一个不

错的选择。

对购物转账等电商和金融业务，中间件层的2PC最大问题在于业务不可见，一旦出现不可抗力或意想不

到的一致性破坏，如数据节点永久性宕机，业务难以根据2PC的日志进行补偿。金融场景下，数据一致

性是命根，业务需要对数据有百分之百的掌控力，建议使用TCC这类分布式事务模型，或基于消息队列

的柔性事务框架，这两种方案都在业务层实现，业务开发者具有足够掌控力，可以结合SOA框架来架

构，包括Dubbo、Spring Cloud等（题主的标签写了Dubbo）。分布式锁的几种实现方式

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

其典型的使用场景为：

不同系统或者是同一系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，需要通过

一定的互斥手段来防止彼此的干扰，以保证一致性。

1. 使用Redis实现分布式锁

* WATCH, MULTI, EXEC, DISCARD事务机制实现分布式锁

Redis支持基本的事务操作

以上被MULTI和EXEC包裹的redis命令，保证所有事务内的命令将会串行顺序执行，保证不会在事务的执

行过程中被其他客户端打断。

而WATCH命令能够监视某个键，当事务执行时，如果被监视的键被其他客户端修改了值，事务运行失

败，返回相应错误（被事务运行客户端在事务内修改了值，不会造成事务运行失败）。

运用Redis事务所支持的以上特性，可以实现一个分布式锁功能。Python代码如下：

通过WATCH命令监视某个键，当该键未被其他客户端修改值时，事务成功执行。当事务运行过程中，发

现该值被其他客户端更新了值，任务失败，进行重试。

MULTI

some redis command

EXEC

# -*- coding: utf-8 -*-

def acqure_lock_with_watch(conn, lockname, acquire_timeout=10):

pipe = conn.pipeline()

end = time.time() + acquire_timeout

lockname = 'lock:' + lockname

while time.time() < end:

try:

pipe.watch(lockname)

pipe.multi() # 开启事务

# 事务具体内容，对lockname的值进行更新

pipe.execute()

return True

except redis.exceptions.WatchError:

# 事务运行期间，有其他客户端改变了lockname的值，抛出异常，进行重试操作

pass

return False* SETNX实现分布式锁

SETNX：当指定键不存在时，向Redis中添加一个键值对。Redis客户端保证对统一键名称，多个客户端

同时设置其值时，只有一个客户端能够设置成功的原子性。

以上，利用SETNX的原子特性，和Redis的键过期特性，实现了自动过期释放的分布式锁。

* 锁的释放

锁释放的过程，首先检查客户端是否仍然持有该锁，如果持有，则在事务中删除键值对，释放锁的所有

权。

# -*- coding: utf-8 -*-

def acquire_lock_with_timeout(

conn, lockname, acquire_timeout=10, lock_timeout=10):

identifire = str(uuid.uuid4())

lockname = 'lock:' + lockname

lock_timeout = int(math.ceil(lock_timeout))

end = time.time() + acquire_timeout

while time.time() < end:

if conn.setnx(lockname, identifire): # 以锁名称为键，uuid的值为值，redis服务

器setnx保证了只能有一个客户端成功设置键的原子性

conn.expire(lockname, lock_timeout) # 设置键的过期时间，过期自动剔除，释放

锁

return identifire

elif not conn.ttl(lockname): # 当锁未被设置过期时间时，重新设置其过期时间

conn.expire(lockname, lock_timeout)

time.sleep(0.001)

return False

# -*- coding: utf-8 -*-

def release_lock(conn, lockname, identifire):

pipe = conn.pipeline(True)

lockname = 'lock:' + lockname

while True:

try:

pipe.watch(lockname) # 监视锁的键，在锁释放过程中改变了键的值时得到相应通知

if pipe.get(lockname) == identifire: # 检查客户端是否仍然持有该锁

pipe.multi()

pipe.delete(lockname) # 删除键，释放锁

pipe.execute()

return True

pipe.unwatch()

break

except redis.exceptions.WatchError:

pass # 释放锁期间，有其他客户端改变了键值对，锁释放失败，进行循环

return False2. 使用Memcached实现分布式锁

Memcached的add命令，当指定的key不存在时，进行添加，且保证了执行的原子性。利用该特性，可

以实现一个分布式锁实现。

释放锁时，删除指定key的键即可。

3. 使用ZooKeeper实现分布式锁

相较于使用redis和memcached实现的锁，zk利用其高级特性，能够实现更复杂的锁特性。

排它锁

排它锁，又称写锁或独占锁。如果事务T1对对象O1加了排它锁，那么整个加锁期间，只允许事务T1对

O1进行读取和更新操作，其他任何事务都不能对该数据对象进行任务读写操作，直到T1释放了排它锁。

以上介绍的使用redis和memcached实现的分布式锁都属于排它锁。

获取锁

ZooKeeper实现分布式锁利用了其临时子节点的如下特性：

在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock，zk会保证在所有的客户端中，最终只有

一个客户端能够创建成功，即可以认为该客户端获得了锁。同时，虽有没有获取到所得客户端需要

到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。

释放锁

因为在获取锁时，创建的是一个临时节点/exclusive_lock/lock，因此在如下情况，都有可能释放锁：

获取锁的机器发生宕机，临时节点被zk移除

正常执行业务逻辑后，客户端主动删除临时节点

无论什么情况下，lock节点被移除，zk都会通知所有在/exclusive_lock节点上注册了子节点变更的

Watcher监听的客户端。这些客户端在收到通知后，重新发起分布式锁的获取流程。

共享锁

共享锁又称读锁。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其

他事务也只能对这个数据对象加上共享锁，直到该数据对象上的所有共享锁都被释放。

而更新操作只能在当前没有任何事务进行读写操作的情况下进行。

def acquire_lock_with__memcached_timeout(

conn, lockname, acquire_timeout=10, lock_timeout=10):

identifire = str(uuid.uuid4())

lockname = 'lock:' + lockname

lock_timeout = int(math.ceil(lock_timeout))

end = time.time() + acquire_timeout

while time.time() < end:

# 过期时间保证了客户端崩溃时仍能在超过过期世家后正常释放锁

# 以锁名称为键，uuid的值为值，memcached服务器add保证了只能有一个客户端成功设置键的原

子性

if conn.add(lockname, identifire, lock_timeout):

return identifire

time.sleep(0.001)

return False获取锁

当需要获取共享锁是，所有客户端到/shared_lock节点下面创建一个临时顺序节

点，/shared_lock/[hostname]-请求类型（W | R）-序号，该节点代编了一个共享锁。

如果是读请求，则创建/shared_lock/192.168.0.1-R-000000000001；

如果是写请求，则创建/shared_lock/192.168.0.1-W-000000000001；

判断读写顺序

1. 在创建完监听后，获取/shared_lock节点下的所有子节点，对该节点注册子节点变更的Watcher监

听

2. 确定自己的节点序号在所有子节点的顺序

3. 对于读请求：

如果没有比自己序号小的子节点，或是所有比自己序号小的子节点都是读请求，那么表明自己已经

成功获取到了共享锁，执行读取逻辑。

如果比自己序号小的子节点中有写请求，那么进入等待。

1. 对于写请求：

如果自己不是序号最小的子节点，那么进入等待。

1. 收到Watcher通知后，重复步骤1-4

释放锁

释放锁，删除对应的数据节点即可。

Spring Cloud面试题

什么是 Spring Cloud？

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。

Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

使用 Spring Cloud 有什么优势？

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

• 与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

• 服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该

目录中注册服务，然后能够查找并连接到该目录中的服务。

• 冗余-分布式系统中的冗余问题。

• 负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处

理单元，或磁盘驱动器的分布。

• 性能-问题由于各种运营开销导致的性能问题。• 部署复杂性-Devops 技能的要求。

服务注册和发现是什么意思？Spring Cloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添

加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可

能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器

上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计

算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一

资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载

平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

什么是 Hystrix？它如何实现容错？

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的

故障时，停止级联故障并在复杂的分布式系统中实现弹性。

通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

思考以下微服务

假设如果上图中的微服务 9 失败了，那么使用传统方法我们将传播一个异常。但这仍然会导致整个系统

崩溃。

随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达 1000.这是 hystrix 出现的地方

我们将使用 Hystrix 在这种情况下的 Fallback 方法功能。我们有两个服务 employee-consumer 使用由

employee-consumer 公开的服务。

简化图如下所示现在假设由于某种原因，employee-producer 公开的服务会抛出异常。我们在这种情况下使用 Hystrix

定义了一个回退方法。这种后备方法应该具有与公开服务相同的返回类型。如果暴露服务中出现异常，

则回退方法将返回一些值。

什么是Hystrix 断路器？我们需要它吗？

由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用 Hystrix 我们定义了一

个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。

如果 firstPage method() 中的异常继续发生，则 Hystrix 电路将中断，并且员工使用者将一起跳过

firtsPage 方法，并直接调用回退方法。断路器的目的是给第一页方法或第一页方法可能调用的其他方法

留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复

机会。什么是 Netflix Feign？它的优点是什么？

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。Feign 的第一个目标是

将约束分母的复杂性统一到 http apis，而不考虑其稳定性。在 employee-consumer 的例子中，我们使

用了 employee-producer 使用 REST 模板公开的 REST 服务。

但是我们必须编写大量代码才能执行以下步骤

· 使用功能区进行负载平衡。

· 获取服务实例，然后获取基本 URL。

· 利用 REST 模板来使用服务。前面的代码如下

之前的代码，有像 NullPointer 这样的例外的机会，并不是最优的。我们将看到如何使用 Netflix Feign

使呼叫变得更加轻松和清洁。如果 Netflix Ribbon 依赖关系也在类路径中，那么 Feign 默认也会负责负

载平衡。

什么是 Spring Cloud Bus？我们需要它吗？

考虑以下情况：我们有多个应用程序使用 Spring Cloud Config 读取属性，而 Spring Cloud Config 从

GIT 读取这些属性。

下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产。

1. @Controller

2. public class ConsumerControllerClient { 3.

4. @Autowired

5. private LoadBalancerClient loadBalancer; 6.

7. public void getEmployee() throws RestClientException, IOException {

9. ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");

10.

11.System.out.println(serviceInstance.getUri());

12.

13.String baseUrl=serviceInstance.getUri().toString();

14.

15.baseUrl=baseUrl+"/employee";

16.

17.RestTemplate restTemplate = new RestTemplate();

18. ResponseEntity<String> response=null;

19. try{

20. response=restTemplate.exchange(baseUrl,

21. HttpMethod.GET, getHeaders(),String.class);

22. }catch (Exception ex)

23. {

24. System.out.println(ex);

25. }

26. System.out.println(response.getBody());

27. }如果假设 GIT 中的 Eureka 注册属性更改为指向另一台 Eureka 服务器，会发生什么情况。在这种情况

下，我们将不得不重新启动服务以获取更新的属性。

还有另一种使用执行器端点/刷新的方式。但是我们将不得不为每个模块单独调用这个 url。例如，如果

Employee Producer1 部署在端口 8080 上，则调用 http：// localhost：8080 / refresh。同样对于

Employee Producer2 http：// localhost：8081 / refresh 等等。这又很麻烦。这就是 Spring Cloud

Bus 发挥作用的地方。 Spring Cloud Bus 提供了跨多个实例刷新配置的功能。因此，在上面的示例中，如果我们刷新

Employee Producer1，则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行，这特

别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到

侦听此代理的所有微服务，并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的

刷新。

为什么需要学习Spring Cloud

不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。但是，

随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。这就会给应用带来

如下的几个问题：

代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。同时，这也会给业务的快速迭代带来

巨大挑战；

开发效率变低：开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过

程，这会严重的影响开发效率；

排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需

要重新编译、打包、上线，成本很高。

由于单体结构的应用随着系统复杂度的增高，会暴露出各种各样的问题。近些年来，微服务架构逐渐取

代了单体架构，且这种趋势将会越来越流行。Spring

Cloud是目前最常用的微服务开发框架，已经在企业级开发中大量的应用。

什么是Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础

设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都

可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家

公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了

复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具

包。

设计目标与优缺点

设计目标

协调各个微服务，简化分布式系统开发。

优缺点

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring

Cloud的呢？

优点：

产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完

善

组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务

发现、断路器、微服务网关等；Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案服务拆分粒度更细，耦

合度比较低，有利于资源重复利用，有利于提高开发效率可以更精准的制定优化服务方案，提高系

统的可维护性减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发微服

务可以是跨平台的，可以用任何一种语言开发适于互联网时代，产品迭代周期更短

缺点：

微服务过多，治理成本高，不利于维护系统

分布式系统开发的成本高（容错，分布式事务等）对团队挑战大总的来说优点大过于缺点，目前看

来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势

是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。

Spring Cloud发展前景

Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金

投入去开发自己的分布式系统基础设施，使用Spring

Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构

和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，

尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年

Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

整体架构

主要项目

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架"Spring

Boot化"的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如

Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。

Spring Cloud Config

集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置

的刷新及加密、解密操作。Spring Cloud Netflix

Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。

Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；

Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；

Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；

Feign：基于Ribbon和Hystrix的声明式服务调用组件；

Zuul：API网关组件，对请求提供路由及过滤功能。

Spring Cloud Bus

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新

集群中的服务配置。

Spring Cloud Consul

基于Hashicorp Consul的服务治理组件。

Spring Cloud Security

安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。

Spring Cloud Sleuth

Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟

踪。

Spring Cloud Stream

轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka

及RabbitMQ。

Spring Cloud Task

用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。

Spring Cloud Zookeeper

基于Apache Zookeeper的服务治理组件。

Spring Cloud Gateway

API网关组件，对请求提供路由及过滤功能。

Spring Cloud OpenFeign

基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC 注解的接口实现用于服务

调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。

Spring Cloud的版本关系

Spring Cloud是一个由许多子项目组成的综合项目，各子项目有不同的发布节奏。为了管理Spring

Cloud与各子项目的版本依赖关系，发布了一个清单，其中包括了某个Spring Cloud版本对应的子项目

版本。为了避免Spring Cloud版本号与子项目版本号混淆，Spring Cloud版本采用了名称而非版本号的

命名，Spring Cloud Version

SpringBo ot Version

Hoxton

2.2.x

Greenwic h

2.1.x

Finchley

2.0.x

Edgware

1.5.x

Dalston

1.5.x

More Actions Compon ent

Edgware. SR6

Greenwic h.SR2

spring- cloud- bus

1.3.4.RELE ASE

2.1.2.RELE ASE

spring- cloud- commons

1.3.6.RELE ASE

2.1.2.RELE ASE

spring- cloud- config

1.4.7.RELE ASE

2.1.3.RELE ASE

spring- cloud- netflix

1.4.7.RELE ASE

2.1.2.RELE ASE

spring- cloud- security

1.2.4.RELE ASE

2.1.3.RELE ASE

spring- cloud- consul

1.3.6.RELE ASE

2.1.2.RELE ASE

spring- cloud- sleuth

1.3.6.RELE ASE

2.1.1.RELE ASE

spring- cloud- stream

Ditmars.S R5

Fishtown. SR3

spring- cloud- zookeepe r

1.2.3.RELE ASE

2.1.2.RELE ASE

spring- boot

1.5.21.REL EASE

2.1.5.RELE ASE

spring- cloud- task

1.2.4.RELE ASE

2.1.2.RELE ASE

spring- cloud- gateway

1.0.3.RELE ASE

2.1.2.RELE ASE

spring- cloud- openfeig n

暂无

2.1.2.RELE ASE

这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，例如Angel是第一个

版本，Brixton是第二个版本。当Spring Cloud的发布

内容积累到临界点或者一个重大BUG被解决后，会发布一个"service

releases"版本，简称SRX版本，比如Greenwich.SR2就是Spring Cloud发布的 Greenwich版本的第2个

SRX版本。目前Spring Cloud的最新版本是Hoxton。

Spring Cloud和SpringBoot版本对应关系

Spring Cloud和各子项目版本对应关系

注意：Hoxton版本是基于SpringBoot 2.2.x版本构建的，不适用于1.5.x版本。随着2019年8月

SpringBoot 1.5.x版本停止维护，Edgware版本也将停止维护。

SpringBoot和SpringCloud的区别？

SpringBoot专注于快速方便的开发单个个体微服务。SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并

管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局

锁、决策竞选、分布式会话等等集成服务

SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot ，属于依赖

的关系

SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

（

1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

（

2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在

该目录中注册服务，然后能够查找并连接到该目录中的服务。

（

3）冗余-分布式系统中的冗余问题。

（

4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中

央处理单元，或磁盘驱动器的分布。

（

5）性能-问题由于各种运营开销导致的性能问题。

（

6）部署复杂性-Devops 技能的要求。

服务注册和发现是什么意思？Spring Cloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添

加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可

能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器

上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

Spring Cloud 和dubbo区别?

（

1）服务调用方式 dubbo是RPC springcloud Rest Api （

2）注册中心,dubbo 是zookeeper

springcloud是eureka，也可以是 zookeeper

（

3）服务网关,dubbo本身没有实现，只能通过其他第三方技术整合， springcloud有Zuul路由网关，

作为路由服务器，进行消费者的请求分

发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服

务自动装配等等一系列的微服务架构要素。

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计

算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一

资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载

平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

什么是 Hystrix？它如何实现容错？

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的

故障时，停止级联故障并在复杂的分布式系统中实现弹性。

通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

思考以下微服务假设如果上图中的微服务 9 失败了，那么使用传统方法我们将传播一个异常。

但这仍然会导致整个系统崩溃。

随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达 1000.

这是 hystrix 出现的地方我们将使用 Hystrix 在这种情况下的 Fallback 方法功

能。我们有两个服务 employee-consumer 使用由 employee-consumer 公开的服务。

简化图如下所示

现在假设由于某种原因，employee-producer 公开的服务会抛出异常。我们在这种情况下使用 Hystrix

定义了一个回退方法。这种后备方法应该具有与公开服

务相同的返回类型。如果暴露服务中出现异常，则回退方法将返回一些值。

什么是 Hystrix 断路器？我们需要它吗？

由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用Hystrix 我们定义了一个

回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。如果 firstPage method() 中的异常继续发生，则 Hystrix 电路将中断，并且员

工使用者将一起跳过 firtsPage 方法，并直接调用回退方法。断路器的目的是给第一页方法或第一页方

法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异

常的问题有更好的恢复机会。

什么是 Netflix Feign？它的优点是什么？

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。

Feign 的第一个目标是将约束分母的复杂性统一到 http apis，而不考虑其稳定性。

在 employee-consumer 的例子中，我们使用了 employee-producer 使用 REST模板公开的 REST 服

务。

但是我们必须编写大量代码才能执行以下步骤（

1）使用功能区进行负载平衡。

（

2）获取服务实例，然后获取基本 URL。

（

3）利用 REST 模板来使用服务。前面的代码如下

1 @Controller

2 public class ConsumerControllerClient {

3 @Autowired

4 private LoadBalancerClient loadBalancer;

5 public void getEmployee() throws RestClientException, IOException {

6 ServiceInstance serviceInstance=loadBalancer.choose("employee- producer");

7 System.out.println(serviceInstance.getUri());

8 String baseUrl=serviceInstance.getUri().toString();

9 baseUrl=baseUrl+"/employee";

10 RestTemplate restTemplate = new RestTemplate();

11 ResponseEntity<String> response=null;

12 try{

13 response=restTemplate.exchange(baseUrl,

14 HttpMethod.GET, getHeaders(),String.class);

15 }

16 catch (Exception ex)

17 {

18 System.out.println(ex);

19 }

20 System.out.println(response.getBody());

21 }之前的代码，有像 NullPointer 这样的例外的机会，并不是最优的。我们将看到如何使用 Netflix Feign

使呼叫变得更加轻松和清洁。如果 Netflix Ribbon 依赖关系也在类路径中，那么 Feign 默认也会负责负

载平衡。

什么是 Spring Cloud Bus？我们需要它吗？

考虑以下情况：我们有多个应用程序使用 Spring Cloud Config 读取属性，而

Spring Cloud Config 从 GIT 读取这些属性。

下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产。

如果假设 GIT 中的 Eureka 注册属性更改(img)为指向另一台 Eureka 服务器，会发生什么情况。在这种

情况下，我们将不得不重新启动服务以获取更新的属性。还有另一种使用执行器端点/刷新的方式。但是

我们将不得不为每个模块单独调

用这个 url。例如，如果 Employee Producer1 部署在端口 8080 上，则调用 http：// localhost：8080

/ refresh。同样对于 Employee Producer2

http：//localhost：8081 / refresh 等等。这又很麻烦。这就是 Spring Cloud Bus 发挥作用的地方。Spring Cloud Bus 提供了跨多个实例刷新配置的功能。因此，在上面的示例中，如果我们刷新

Employee Producer1，则会自动刷新所有其他必需的模

块。如果我们有多个微服务启动并运行，这特别有用。这是通过将所有微服务连接到单个消息代理来实

现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。可以通过

使用端点/总线/刷新来实现对任何单个实例的刷新。

Spring Cloud断路器的作用

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应当更多

的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）断路器有完全打开状态:一段时

间内达到一定的次数无法调用并且多次监测没有恢复的迹象断路器完全打开那么下次请求就不会请求

到该服务半开:短时间内有恢复迹象断路器会将部分请求发给该服务，正常调用时断路器关闭

关闭：当服务一直处于正常状态能正常调用

什么是Spring Cloud Config?

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配

置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配

置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，

一是 config server，二是config client。

使用：

（

1）添加pom依赖

（

2）配置文件添加相关配置

（

3）启动类添加注解@EnableConfigServer什么是Spring Cloud Gateway?

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul 网关。网关作为流量的，

在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由

RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根

据具体的请求的规则，由具体的route去处理，filters 是各种过滤器，用来对请求做各种判断和修改。

一. 分布式模型

1. 节点

在具体的工程项目中，一个节点往往是一个操作系统上的进程。在本文的模型中，认为节点是一个完整

的、不可分的整体，如果某个程序进程实际上由若干相对独立部分构成，则在模型中可以将一个进程划

分为多个节点。

异常

机器宕机：机器宕机是最常见的异常之一。在大型集群中每日宕机发生的概率为千分之一左右，在实践

中，一台宕机的机器恢复的时间通常认为是24 小时，一般需要人工介入重启机器。

网络异常：消息丢失，两片节点之间彼此完全无法通信，即出现了“网络分化”；消息乱序，有一定的概

率不是按照发送时的顺序依次到达目的节点，考虑使用序列号等机制处理网络消息的乱序问题，使得无

效的、过期的网络消息不影响系统的正确性；数据错误；不可靠的TCP，TCP 协议为应用层提供了可靠

的、面向连接的传输服务，但在分布式系统的协议设计中不能认为所有网络通信都基于TCP 协议则通信

就是可靠的。TCP协议只能保证同一个TCP 链接内的网络消息不乱序，TCP 链接之间的网络消息顺序则

无法保证。

分布式三态：如果某个节点向另一个节点发起RPC(Remote procedure call) 调用，即某个节点A 向另一

个节点B 发送一个消息，节点B 根据收到的消息内容完成某些操作，并将操作的结果通过另一个消息返

回给节点A，那么这个RPC 执行的结果有三种状态：“成功”、“失败”、“超时（未知）”，称之为分布式系

统的三态。

存储数据丢失：对于有状态节点来说，数据丢失意味着状态丢失，通常只能从其他节点读取、恢复存储

的状态。

异常处理原则：被大量工程实践所检验过的异常处理黄金原则是：任何在设计阶段考虑到的异常情况一

定会在系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非

需求指标允许，在系统设计时不能放过任何异常情况。

副本

副本（replica/copy）指在分布式系统中为数据或服务提供的冗余。对于数据副本指在不同的节点上持

久化同一份数据，当出现某一个节点的存储的数据丢失时，可以从副本上读到数据。数据副本是分布式

系统解决数据丢失异常的唯一手段。另一类副本是服务副本，指数个节点提供某种相同的服务，这种服

务一般并不依赖于节点的本地存储，其所需数据一般来自其他节点。

副本协议是贯穿整个分布式系统的理论核心。

副本一致性

分布式系统通过副本控制协议，使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相

同，称之为副本一致性(consistency)。副本一致性是针对分布式系统而言的，不是针对某一个副本而

言。1. 强一致性(strong consistency)：任何时刻任何用户或节点都可以读到最近一次成功更新的副本数

据。强一致性是程度最高的一致性要求，也是实践中最难以实现的一致性。

2. 单调一致性(monotonic consistency)：任何时刻，任何用户一旦读到某个数据在某次更新后的

值，这个用户不会再读到比这个值更旧的值。单调一致性是弱于强一致性却非常实用的一种一致性

级别。因为通常来说，用户只关心从己方视角观察到的一致性，而不会关注其他用户的一致性情

况。

3. 会话一致性(session consistency)：任何用户在某一次会话内一旦读到某个数据在某次更新后的

值，这个用户在这次会话过程中不会再读到比这个值更旧的值。会话一致性通过引入会话的概念，

在单调一致性的基础上进一步放松约束，会话一致性只保证单个用户单次会话内数据的单调修改，

对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。实践中有许多机制正好对应

会话的概念，例如php 中的session 概念。

4. 最终一致性(eventual consistency)：最终一致性要求一旦更新成功，各个副本上的数据最终将达

到完全一致的状态，但达到完全一致状态所需要的时间不能保障。对于最终一致性系统而言，一个

用户只要始终读取某一个副本的数

据，则可以实现类似单调一致性的效果，但一旦用户更换读取的副本，则无法保障任何一致性。

5. 弱一致性(week consistency)：一旦某个更新成功，用户无法在一个确定时间内读到这次更新的

值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。弱一致性系统

一般很难在实际中使用，使用弱一致性系统需要应用方做更多的工作从而使得系统可用。

3. 衡量分布式系统的指标

性能：系统的吞吐能力，指系统在某一时间可以处理的数据总量，通常可以用系统每秒处理的总的数据

量来衡量；系统的响应延迟，指系统完成某一功能需要使用的时间；系统的并发能力，指系统可以同时

完成某一功能的能力，通常也用QPS(query per second)来衡量。上述三个性能指标往往会相互制约，

追求高吞吐的系统，往往很难做到低延迟；系统平均响应时间较长时，也很难提高QPS。

可用性：系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。系统的可用性

可以用系统停服务的时间与正常服务的时间的比例来衡量，也可以用某功能的失败次数与成功次数的比

例来衡量。可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。

可扩展性：系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延

迟、并发）、存储容量、计算能力的特性。好的分布式系统总在追求“线性扩展性”，也就是使得系统的

某一指标可以随着集群中的机器数量线性增长。

一致性：分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本一致性的问题。

越是强的一致的性模型，对于用户使用来说使用起来越简单。

posted @ 2023-06-09 15:38 十一vs十一阅读(51) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

BAT面试题汇总及详解(进大厂必看)02 前面一般有用 看3

公告

BAT面试题汇总及详解(进大厂必看)02 前面一般有用看3