代码拉取完成，页面将自动刷新
Fork 仓库
加载中
确定同步？
同步操作将从 linc5403/webapp 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
项目选题
论坛
团队协作
电商
技术
基础
单元测试
多环境配置
设计模式
单例(Singleton)
- 懒汉式，线程不安全
是否 Lazy 初始化：是
是否多线程安全：否
描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
public class SingleObject {
//创建 SingleObject 的一个对象
private static SingleObject instance = new SingleObject();
//让构造函数为 private，这样该类就不会被实例化
private SingleObject(){}
//获取唯一可用的对象
public static SingleObject getInstance(){
return instance;
}
public void showMessage(){
System.out.println("Hello World!");
}
}
public class SingletonPatternDemo {
public static void main(String[] args) {
//不合法的构造函数
//编译时错误：构造函数 SingleObject() 是不可见的
//SingleObject object = new SingleObject();
//获取唯一可用的对象
SingleObject object = SingleObject.getInstance();
//显示消息
object.showMessage();
}
}
- 懒汉式，线程安全
是否 Lazy 初始化：是
是否多线程安全：是
描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
- 饿汉式
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述：这种方式比较常用，但容易产生垃圾对象。
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。
它基于 classloader 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
工厂模式
使用工厂类的抽象方法来实例化一个对象:
Spring自身就是Factory pattern的完美示例. 工厂模式被运用于整个框架中, 最主要的是BeanFactory类.
- 目的: Factory pattern 允许使用工厂方法创建相似累的不同对象, 所创建的对象应当共享接口或是子类关系
- 实现:
- 创建通用接口
- 构建创造接口的类
- 实现实例化的方法
- Spring BeanFactory Container (e.g org.springframework.beans.factory.BeanFactory)
提供DI基础支持的最简单容器
- Spring ApplicationContext Container (e.g [org.springframework.context.ApplicationContext])
容器启动的时候，不管你用没用到，一次性创建所有 bean 。BeanFactory 仅提供了最基本的依赖注入支持，ApplicationContext 扩展了 BeanFactory, 除了有BeanFactory的功能还有额外更多功能，所以一般开发人员使用ApplicationContext会更多。
构造器模式
代理模式
AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。 Spring AOP 就是基于动态代理的，如果要代理的对象，实现了某个接口，那么Spring AOP会使用JDK Proxy，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候Spring AOP会使用Cglib ，这时候Spring AOP会使用 Cglib 生成一个被代理对象的子类来作为代理
Spring 的骨骼架构
Spring 总共有十几个组件，但是真正核心的组件只有几个，下面是 Spring 框架的总体架构图：
从上图中可以看出 Spring 框架中的核心组件只有三个：Core、Context 和 Beans。它们构建起了整个 Spring 的骨骼架构。没有它们就不可能有 AOP、Web 等上层的特性功能。下面也将主要从这三个组件入手分析 Spring。
Spring 的设计理念
前面介绍了 Spring 的三个核心组件，如果再在它们三个中选出核心的话，那就非 Beans 组件莫属了，为何这样说，其实 Spring 就是面向 Bean 的编程（BOP,Bean Oriented Programming），Bean 在 Spring 中才是真正的主角。
Bean 在 Spring 中作用就像 Object 对 OOP 的意义一样，没有对象的概念就像没有面向对象编程，Spring 中没有 Bean 也就没有 Spring 存在的意义。就像一次演出舞台都准备好了但是却没有演员一样。为什么要 Bean 这种角色 Bean 或者为何在 Spring 如此重要，这由 Spring 框架的设计目标决定，Spring 为何如此流行，我们用 Spring 的原因是什么，想想你会发现原来 Spring 解决了一个非常关键的问题他可以让你把对象之间的依赖关系转而用配置文件来管理，也就是他的依赖注入机制。而这个注入关系在一个叫 Ioc 容器中管理，那 Ioc 容器就是被 Bean 包裹的对象。Spring 正是通过把对象包装在 Bean 中而达到对这些对象的管理以及一些列额外操作的目的。
它这种设计策略完全类似于 Java 实现 OOP 的设计理念，当然了 Java 本身的设计要比 Spring 复杂太多太多，但是都是构建一个数据结构，然后根据这个数据结构设计他的生存环境，并让它在这个环境中按照一定的规律在不停的运动，在它们的不停运动中设计一系列与环境或者与其他个体完成信息交换。这样想来我们用到的其他框架都是大慨类似的设计理念。
核心组件如何协同工作
前面说 Bean 是 Spring 中关键因素，那 Context 和 Core 又有何作用呢？前面把 Bean 比作一场演出中的演员的话，那 Context 就是这场演出的舞台背景，而 Core 应该就是演出的道具了。只有他们在一起才能具备演出一场好戏的最基本条件。当然有最基本的条件还不能使这场演出脱颖而出，还要他表演的节目足够的精彩，这些节目就是 Spring 能提供的特色功能了。
我们知道 Bean 包装的是 Object，而 Object 必然有数据，如何给这些数据提供生存环境就是 Context 要解决的问题，对 Context 来说他就是要发现每个 Bean 之间的关系，为它们建立这种关系并且要维护好这种关系。所以 Context 就是一个 Bean 关系的集合，这个关系集合又叫 Ioc 容器，一旦建立起这个 Ioc 容器后 Spring 就可以为你工作了。那 Core 组件又有什么用武之地呢？其实 Core 就是发现、建立和维护每个 Bean 之间的关系所需要的一些列的工具，从这个角度看来，Core 这个组件叫 Util 更能让你理解。
它们之间可以用下图来表示：
核心组件详解
这里将详细介绍每个组件内部类的层次关系，以及它们在运行时的时序顺序。我们在使用 Spring 是应该注意的地方。
Bean 组件
前面已经说明了 Bean 组件对 Spring 的重要性，下面看看 Bean 这个组件式怎么设计的。Bean 组件在 Spring 的 org.springframework.beans 包下。这个包下的所有类主要解决了三件事：Bean 的定义、Bean 的创建以及对 Bean 的解析。对 Spring 的使用者来说唯一需要关心的就是 Bean 的创建，其他两个由 Spring 在内部帮你完成了，对你来说是透明的。
Spring Bean 的创建时典型的工厂模式，它的顶级接口是 BeanFactory，下图是这个工厂的继承层次关系：
BeanFactory 有三个子类：ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory。但是从上图中我们可以发现最终的默认实现类是 DefaultListableBeanFactory，实现了所有的接口。那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有使用的场合，它主要是为了区分在 Spring 内部对象的传递和转化过程中，对对象的数据访问所做的限制。例如 ListableBeanFactory 接口表示这些 Bean 是可列表的，而 HierarchicalBeanFactory 表示的这些 Bean 是有继承关系的，也就是每个 Bean 有可能有父 Bean。AutowireCapableBeanFactory 接口定义 Bean 的自动装配规则。这四个接口共同定义了 Bean 的集合、Bean 之间的关系、以及 Bean 行为。
Bean 的定义主要有 BeanDefinition 描述，如下图说明了这些类的层次关系：
Bean 的定义就是完整的描述了在 Spring 的配置文件中你定义的 <bean/> 节点中所有的信息，包括各种子节点。当 Spring 成功解析你定义的一个 <bean/> 节点后，在 Spring 的内部就被转化成 BeanDefinition 对象。以后所有的操作都是对这个对象完成的。
Bean 的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean 的解析主要就是对 Spring 配置文件的解析。这个解析过程主要通过下图中的类完成：
当然还有具体对 tag 的解析这里并没有列出。
Context 组件
Context 在 Spring 的 org.springframework.context 包下，前面已经讲解了 Context 组件在 Spring 中的作用，他实际上就是给 Spring 提供一个运行时的环境，用以保存各个对象的状态。下面看一下这个环境是如何构建的。
ApplicationContext 是 Context 的顶级父类，他除了能标识一个应用环境的基本信息外，他还继承了五个接口，这五个接口主要是扩展了 Context 的功能。下面是 Context 的类结构图：
从上图中可以看出 ApplicationContext 继承了 BeanFactory，这也说明了 Spring 容器中运行的主体对象是 Bean，另外 ApplicationContext 继承了 ResourceLoader 接口，使得 ApplicationContext 可以访问到任何外部资源，这将在 Core 中详细说明。
ApplicationContext 的子类主要包含两个方面：
- ConfigurableApplicationContext 表示该 Context 是可修改的，也就是在构建 Context 中用户可以动态添加或修改已有的配置信息，它下面又有多个子类，其中最经常使用的是可更新的 Context，即 AbstractRefreshableApplicationContext 类。
- WebApplicationContext 顾名思义，就是为 web 准备的 Context 他可以直接访问到 ServletContext，通常情况下，这个接口使用的少。
再往下分就是按照构建 Context 的文件类型，接着就是访问 Context 的方式。这样一级一级构成了完整的 Context 等级层次。
总体来说 ApplicationContext 必须要完成以下几件事：
- 标识一个应用环境
- 利用 BeanFactory 创建 Bean 对象
- 保存对象关系表
- 能够捕获各种事件
Context 作为 Spring 的 Ioc 容器，基本上整合了 Spring 的大部分功能，或者说是大部分功能的基础。
Core 组件
Core 组件作为 Spring 的核心组件，他其中包含了很多的关键类，其中一个重要组成部分就是定义了资源的访问方式。这种把所有资源都抽象成一个接口的方式很值得在以后的设计中拿来学习。下面就重要看一下这个部分在 Spring 的作用。
下图是 Resource 相关的类结构图：
从上图可以看出 Resource 接口封装了各种可能的资源类型，也就是对使用者来说屏蔽了文件类型的不同。对资源的提供者来说，如何把资源包装起来交给其他人用这也是一个问题，我们看到 Resource 接口继承了 InputStreamSource 接口，这个接口中有个 getInputStream 方法，返回的是 InputStream 类。这样所有的资源都被可以通过 InputStream 这个类来获取，所以也屏蔽了资源的提供者。另外还有一个问题就是加载资源的问题，也就是资源的加载者要统一，从上图中可以看出这个任务是由 ResourceLoader 接口完成，他屏蔽了所有的资源加载者的差异，只需要实现这个接口就可以加载所有的资源，他的默认实现是 DefaultResourceLoader。
下面看一下 Context 和 Resource 是如何建立关系的？首先看一下他们的类关系图：
从上图可以看出，Context 是把资源的加载、解析和描述工作委托给了 ResourcePatternResolver 类来完成，他相当于一个接头人，他把资源的加载、解析和资源的定义整合在一起便于其他组件使用。Core 组件中还有很多类似的方式。
Ioc 容器如何工作
前面介绍了 Core 组件、Bean 组件和 Context 组件的结构与相互关系，下面这里从使用者角度看一下他们是如何运行的，以及我们如何让 Spring 完成各种功能，Spring 到底能有那些功能，这些功能是如何得来的，下面介绍。
如何创建 BeanFactory 工厂
Ioc 容器实际上就是 Context 组件结合其他两个组件共同构建了一个 Bean 关系网，如何构建这个关系网？构建的入口就在 AbstractApplicationContext 类的 refresh 方法中。这个方法的代码如下：
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
initMessageSource();
// Initialize event multicaster for this context.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
onRefresh();
// Check for listener beans and register them.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
finishRefresh();
}
catch (BeansException ex) {
// Destroy already created singletons to avoid dangling resources.
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
}
}
这个方法就是构建整个 Ioc 容器过程的完整的代码，了解了里面的每一行代码基本上就了解大部分 Spring 的原理和功能了。
这段代码主要包含这样几个步骤：
- 构建 BeanFactory，以便于产生所需的“演员”
- 注册可能感兴趣的事件
- 创建 Bean 实例对象
- 触发被监听的事件
下面就结合代码分析这几个过程。
第二三句就是在创建和配置 BeanFactory。这里是 refresh 也就是刷新配置，前面介绍了 Context 有可更新的子类，这里正是实现这个功能，当 BeanFactory 已存在是就更新，如果没有就新创建。下面是更新 BeanFactory 的方法代码：
AbstractRefreshableApplicationContext. refreshBeanFactory
protected final void refreshBeanFactory() throws BeansException {
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException(
"I/O error parsing bean definition source for "
+ getDisplayName(), ex);
}
}
这个方法实现了 AbstractApplicationContext 的抽象方法 refreshBeanFactory，这段代码清楚的说明了 BeanFactory 的创建过程。注意 BeanFactory 对象的类型的变化，前面介绍了他有很多子类，在什么情况下使用不同的子类这非常关键。BeanFactory 的原始对象是 DefaultListableBeanFactory，这个非常关键，因为他设计到后面对这个对象的多种操作，下面看一下这个类的继承层次类图：
从这个图中发现除了 BeanFactory 相关的类外，还发现了与 Bean 的 register 相关。这在 refreshBeanFactory 方法中有一行 loadBeanDefinitions(beanFactory) 将找到答案，这个方法将开始加载、解析 Bean 的定义，也就是把用户定义的数据结构转化为 Ioc 容器中的特定数据结构。
这个过程可以用下面时序图解释：
创建 BeanFactory 时序图
Bean 的解析和登记流程时序图如下：
创建好 BeanFactory 后，接下去添加一些 Spring 本身需要的一些工具类，这个操作在 AbstractApplicationContext 的 prepareBeanFactory 方法完成。
AbstractApplicationContext 中接下来的三行代码对 Spring 的功能扩展性起了至关重要的作用。前两行主要是让你现在可以对已经构建的 BeanFactory 的配置做修改，后面一行就是让你可以对以后再创建 Bean 的实例对象时添加一些自定义的操作。所以他们都是扩展了 Spring 的功能，所以我们要学习使用 Spring 必须对这一部分搞清楚。
其中在 invokeBeanFactoryPostProcessors 方法中主要是获取实现 BeanFactoryPostProcessor 接口的子类。并执行它的 postProcessBeanFactory 方法，这个方法的声明如下：
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
throws BeansException;
它的参数是 beanFactory，说明可以对 beanFactory 做修改，这里注意这个 beanFactory 是 ConfigurableListableBeanFactory 类型的，这也印证了前面介绍的不同 BeanFactory 所使用的场合不同，这里只能是可配置的 BeanFactory，防止一些数据被用户随意修改。
registerBeanPostProcessors 方法也是可以获取用户定义的实现了 BeanPostProcessor 接口的子类，并执行把它们注册到 BeanFactory 对象中的 beanPostProcessors 变量中。BeanPostProcessor 中声明了两个方法：postProcessBeforeInitialization、postProcessAfterInitialization 分别用于在 Bean 对象初始化时执行。可以执行用户自定义的操作。
后面的几行代码是初始化监听事件和对系统的其他监听者的注册，监听者必须是 ApplicationListener 的子类。
如何创建 Bean 实例并构建 Bean 的关系网
下面就是 Bean 的实例化代码，是从 finishBeanFactoryInitialization 方法开始的。
AbstractApplicationContext.finishBeanFactoryInitialization
protected void finishBeanFactoryInitialization(
ConfigurableListableBeanFactory beanFactory) {
// Stop using the temporary ClassLoader for type matching.
beanFactory.setTempClassLoader(null);
// Allow for caching all bean definition metadata, not expecting further changes.
beanFactory.freezeConfiguration();
// Instantiate all remaining (non-lazy-init) singletons.
beanFactory.preInstantiateSingletons();
}
从上面代码中可以发现 Bean 的实例化是在 BeanFactory 中发生的。preInstantiateSingletons 方法的代码如下：
DefaultListableBeanFactory.preInstantiateSingletons
public void preInstantiateSingletons() throws BeansException {
if (this.logger.isInfoEnabled()) {
this.logger.info("Pre-instantiating singletons in " + this);
}
synchronized (this.beanDefinitionMap) {
for (String beanName : this.beanDefinitionNames) {
RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
if (!bd.isAbstract() && bd.isSingleton()
&& !bd.isLazyInit()) {
if (isFactoryBean(beanName)) {
final FactoryBean factory =
(FactoryBean) getBean(FACTORY_BEAN_PREFIX+ beanName);
boolean isEagerInit;
if (System.getSecurityManager() != null
&& factory instanceof SmartFactoryBean) {
isEagerInit = AccessController.doPrivileged(
new PrivilegedAction<Boolean>() {
public Boolean run() {
return ((SmartFactoryBean) factory).isEagerInit();
}
}, getAccessControlContext());
}
else {
isEagerInit = factory instanceof SmartFactoryBean
&& ((SmartFactoryBean) factory).isEagerInit();
}
if (isEagerInit) {
getBean(beanName);
}
}
else {
getBean(beanName);
}
}
}
}
}
这里出现了一个非常重要的 Bean —— FactoryBean，可以说 Spring 一大半的扩展的功能都与这个 Bean 有关，这是个特殊的 Bean 是一个工厂 Bean，可以产生 Bean 的 Bean，这里的产生 Bean 是指 Bean 的实例，如果一个类继承 FactoryBean 用户只要实现他的 getObject 方法，就可以自己定义产生实例对象的方法。然而在 Spring 内部这个 Bean 的实例对象是 FactoryBean，通过调用这个对象的 getObject 方法就能获取用户自定义产生的对象，从而为 Spring 提供了很好的扩展性。Spring 获取 FactoryBean 本身的对象是在前面加上 & 来完成的。
如何创建 Bean 的实例对象以及如何构建 Bean 实例对象之间的关联关系式 Spring 中的一个核心关键，下面是这个过程的流程图。
Bean 实例创建流程图
如果是普通的 Bean 就直接创建他的实例，是通过调用 getBean 方法。下面是创建 Bean 实例的时序图：
Bean 实例创建时序图
还有一个非常重要的部分就是建立 Bean 对象实例之间的关系，这也是 Spring 框架的核心竞争力，何时、如何建立他们之间的关系请看下面的时序图：
Bean 对象关系建立
Ioc 容器的扩展点
现在还有一个问题就是如何让这些 Bean 对象有一定的扩展性，就是可以加入用户的一些操作。那么有哪些扩展点呢？ Spring 又是如何调用到这些扩展点的？
对 Spring 的 Ioc 容器来说，主要有这么几个。BeanFactoryPostProcessor， BeanPostProcessor。他们分别是在构建 BeanFactory 和构建 Bean 对象时调用。还有就是 InitializingBean 和 DisposableBean， 他们分别是在 Bean 实例创建和销毁时被调用。用户可以实现这些接口中定义的方法，Spring 就会在适当的时候调用他们。还有一个是 FactoryBean 他是个特殊的 Bean，这个 Bean 可以被用户更多的控制。
这些扩展点通常也是我们使用 Spring 来完成我们特定任务的地方，如何精通 Spring 就看你有没有掌握好 Spring 有哪些扩展点，并且如何使用他们，要知道如何使用他们就必须了解他们内在的机理。可以用下面一个比喻来解释。
我们把 Ioc 容器比作一个箱子，这个箱子里有若干个球的模子，可以用这些模子来造很多种不同的球，还有一个造这些球模的机器，这个机器可以产生球模。那么他们的对应关系就是：BeanFactory 是那个造球模的机器，球模就是 Bean，而球模造出来的球就是 Bean 的实例。那前面所说的几个扩展点又在什么地方呢？ BeanFactoryPostProcessor 对应到当造球模被造出来时，你将有机会可以对其做出适当的修正，也就是他可以帮你修改球模。而 InitializingBean 和 DisposableBean 是在球模造球的开始和结束阶段，你可以完成一些预备和扫尾工作。BeanPostProcessor 就可以让你对球模造出来的球做出适当的修正。最后还有一个 FactoryBean，它可是一个神奇的球模。这个球模不是预先就定型了，而是由你来给他确定它的形状，既然你可以确定这个球模型的形状，当然他造出来的球肯定就是你想要的球了，这样在这个箱子里你可以发现所有你想要的球。
Ioc 容器如何为我所用
前面的介绍了 Spring 容器的构建过程，那 Spring 能为我们做什么，Spring 的 Ioc 容器又能做什么呢？我们使用 Spring 必须要首先构建 Ioc 容器，没有它 Spring 无法工作，ApplicatonContext.xml 就是 Ioc 容器的默认配置文件，Spring 的所有特性功能都是基于这个 Ioc 容器工作的，比如后面要介绍的 AOP。
Ioc 它实际上就是为你构建了一个魔方，Spring 为你搭好了骨骼架构，这个魔方到底能变出什么好的东西出来，这必须要有你的参与。那我们怎么参与？这就是前面说的要了解 Spring 中有哪些扩展点，我们通过实现那些扩展点来改变 Spring 的通用行为。至于如何实现扩展点来得到我们想要的个性结果，Spring 中有很多例子，其中 AOP 的实现就是 Spring 本身实现了其扩展点来达到了它想要的特性功能，可以拿来参考。
Spring 中 AOP 特性详解
动态代理的实现原理
要了解 Spring 的 AOP 就必须先了解动态代理的原理，因为 AOP 就是基于动态代理实现的。动态代理还要从 JDK 本身说起。
在 Jdk 的 java.lang.reflect 包下有个 Proxy 类，它正是构造代理类的入口。这个类的结构入下：
从上图发现最后面四个是公有方法。而最后一个方法 newProxyInstance 就是创建代理对象的方法。这个方法的源码如下：
Proxy. newProxyInstance
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
throws IllegalArgumentException {
if (h == null) {
throw new NullPointerException();
}
Class cl = getProxyClass(loader, interfaces);
try {
Constructor cons = cl.getConstructor(constructorParams);
return (Object) cons.newInstance(new Object[] { h });
} catch (NoSuchMethodException e) {
throw new InternalError(e.toString());
} catch (IllegalAccessException e) {
throw new InternalError(e.toString());
} catch (InstantiationException e) {
throw new InternalError(e.toString());
} catch (InvocationTargetException e) {
throw new InternalError(e.toString());
}
}
这个方法需要三个参数：ClassLoader，用于加载代理类的 Loader 类，通常这个 Loader 和被代理的类是同一个 Loader 类。Interfaces，是要被代理的那些那些接口。InvocationHandler，就是用于执行除了被代理接口中方法之外的用户自定义的操作，他也是用户需要代理的最终目的。用户调用目标方法都被代理到 InvocationHandler 类中定义的唯一方法 invoke 中。这在后面再详解。
下面还是看看 Proxy 如何产生代理类的过程，他构造出来的代理类到底是什么样子？下面揭晓啦。
其实从上图中可以发现正在构造代理类的是在 ProxyGenerator 的 generateProxyClass 的方法中。ProxyGenerator 类在 sun.misc 包下，感兴趣的话可以看看他的源码。
假如有这样一个接口，如下：
public interface SimpleProxy {
public void simpleMethod1();
public void simpleMethod2();
}
代理来生成的类结构如下：
$Proxy2
public class $Proxy2 extends java.lang.reflect.Proxy implements SimpleProxy{
java.lang.reflect.Method m0;
java.lang.reflect.Method m1;
java.lang.reflect.Method m2;
java.lang.reflect.Method m3;
java.lang.reflect.Method m4;
int hashCode();
boolean equals(java.lang.Object);
java.lang.String toString();
void simpleMethod1();
void simpleMethod2();
}
这个类中的方法里面将会是调用 InvocationHandler 的 invoke 方法，而每个方法也将对应一个属性变量，这个属性变量 m 也将传给 invoke 方法中的 Method 参数。整个代理就是这样实现的。
Spring AOP 如何实现
从前面代理的原理我们知道，代理的目的是调用目标方法时我们可以转而执行 InvocationHandler 类的 invoke 方法，所以如何在 InvocationHandler 上做文章就是 Spring 实现 Aop 的关键所在。
Spring 的 Aop 实现是遵守 Aop 联盟的约定。同时 Spring 又扩展了它，增加了如 Pointcut、Advisor 等一些接口使得更加灵活。
下面是 Jdk 动态代理的类图：
上图清楚的显示了 Spring 引用了 Aop Alliance 定义的接口。姑且不讨论 Spring 如何扩展 Aop Alliance，先看看 Spring 如何实现代理类的，要实现代理类在 Spring 的配置文件中通常是这样定一个 Bean 的，如下：
<bean id="testBeanSingleton"
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyInterfaces">
<value>
org.springframework.aop.framework.PrototypeTargetTests$TestBean
</value>
</property>
<property name="target"><ref local="testBeanTarget"></ref> </property>
<property name="singleton"><value>true</value></property>
<property name="interceptorNames">
<list>
<value>testInterceptor</value>
<value>testInterceptor2</value>
</list>
</property>
</bean>
配置上看到要设置被代理的接口，和接口的实现类也就是目标类，以及拦截器也就在执行目标方法之前被调用，这里 Spring 中定义的各种各样的拦截器，可以选择使用。
下面看看 Spring 如何完成了代理以及是如何调用拦截器的。
前面提到 Spring Aop 也是实现其自身的扩展点来完成这个特性的，从这个代理类可以看出它正是继承了 FactoryBean 的 ProxyFactoryBean，FactoryBean 之所以特别就在于它可以让你自定义对象的创建方法。当然代理对象要通过 Proxy 类来动态生成。
下面是 Spring 创建的代理对象的时序图：
Spring 代理对象的产生
Spring 创建了代理对象后，当你调用目标对象上的方法时，将都会被代理到 InvocationHandler 类的 invoke 方法中执行，这在前面已经解释。在这里 JdkDynamicAopProxy 类实现了 InvocationHandler 接口。
下面再看看 Spring 是如何调用拦截器的，下面是这个过程的时序图：
以上所说的都是 Jdk 动态代理，Spring 还支持一种 CGLIB 类代理
AOP与Transaction
在应用系统调用声明@Transactional 的目标方法时，Spring Framework 默认使用 AOP 代理，在代码运行时生成一个代理对象，根据@Transactional 的属性配置信息，这个代理对象决定该声明@Transactional 的目标方法是否由拦截器 TransactionInterceptor 来使用拦截，在 TransactionInterceptor 拦截时，会在在目标方法开始执行之前创建并加入事务，并执行目标方法的逻辑, 最后根据执行情况是否出现异常，利用抽象事务管理器(图 2 有相关介绍)AbstractPlatformTransactionManager 操作数据源 DataSource 提交或回滚事务, 如图 1 所示。
图 1. Spring 事务实现机制
Spring AOP 代理有 CglibAopProxy 和 JdkDynamicAopProxy 两种，图 1 是以 CglibAopProxy 为例，对于 CglibAopProxy，需要调用其内部类的 DynamicAdvisedInterceptor 的 intercept 方法。对于 JdkDynamicAopProxy，需要调用其 invoke 方法。
正如上文提到的，事务管理的框架是由抽象事务管理器 AbstractPlatformTransactionManager 来提供的，而具体的底层事务处理实现，由 PlatformTransactionManager 的具体实现类来实现，如事务管理器 DataSourceTransactionManager。不同的事务管理器管理不同的数据资源 DataSource，比如 DataSourceTransactionManager 管理 JDBC 的 Connection。
PlatformTransactionManager，AbstractPlatformTransactionManager 及具体实现类关系如图 2 所示。
图 2. TransactionManager 类结构
Bean VS Component
- @Bean用于方法， 表示该方法生成一个对象交由Spring IOC容器进行管理，通常和@Configuration配合使用， 用于配置时生成对象，一般来说不是用于业务的对象。
- @Component用于Class， 表示该Class需要Spring来实例化。
ThreadLocal以及多线程
ThreadLocal
每个线程中的一个Local变量,在该线程的生命周期中有效. 用来隔离线程,使得线程间互不影响.
https://dzone.com/articles/purpose-threadlocal-java-and
使用场景
- 普通Http请求处理
doGet(HttpServletRequest req, HttpServletResponse resp) { User user = getLoggedInUser(req); doSomething(user) doSomethingElse(user) renderResponse(resp,user) }问题: 1. 麻烦 2. 把user对象泄露到多个方法中处理
- 使用ThreadLocal解决
doGet(HttpServletRequest req, HttpServletResponse resp) { User user = getLoggedInUser(req); StaticClass.getThreadLocal().set(user) try { doSomething() doSomethingElse() renderResponse(resp) } finally { StaticClass.getThreadLocal().remove() } }所有需要使用到user对象的地方:
User user = StaticClass.getThreadLocal().get()使用ThreadLocal来管理user对象:
class StaticClass { static private ThreadLocal threadLocal = new ThreadLocal<User>(); static getThreadLocal() { return threadLocal; } }
为什么是static
因为ThreadLocal是依附于Thread存在的,而同一个对象在一个Thread中应当只存在一个实例,因此该对象可以理解为Thread中有且仅有一份,所以是static.
线程同步
synchronized
java的每个对象都有一个内置锁, synchronized 则是使用该内置锁来实现同一时刻有且只能有一个线程可以访问到该对象的锁. 在调用前，需要获得内置锁，否则就处于阻塞状态。
- 同步方法 - 当用此
synchronized修饰方法时，内置锁会保护整个方法
public synchronized void save(){}
- 同步代码块 -
synchronized修饰的语句块会自动被加上内置锁，从而实现同步
synchronized(object){
//...
}
volatile
原理: 读写都直接操作内存,避免CPU Cache造成的非同步状态
- volatile关键字为域变量的访问提供了一种免锁机制
- 使用volatile修饰域相当于告诉虚拟机该域可能会被其他线程更新
- 因此每次使用该域就要重新计算，而不是使用寄存器中的值
- volatile不会提供任何原子操作，它也不能用来修饰final类型的变量
- 对于多个线程同时读写的场景并无任何作用
原子变量
原子操作就是指将读取变量值、修改变量值、保存变量值看成一个整体来操作, 即-这几种行为要么同时完成，要么都不完成。
在java的util.concurrent.atomic包中提供了创建了原子类型变量的工具类，使用该类可以简化线程同步。
AtomicInteger 原子方式更新int的值，可用在应用程序中(如以原子方式增加的计数器)，但不能用于替换Integer；可扩展Number，允许那些处理机遇数字类的工具和实用工具进行统一访问。
class Bank {
private AtomicInteger account = new AtomicInteger(100);
public AtomicInteger getAccount() {
return account;
}
public void save(int money) {
account.addAndGet(money);
}
}
ReentrantLock(重入锁)
ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比Synchronized，ReentrantLock类提供了一些高级功能，主要有以下3项：
- 等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。
- 公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。
- 锁绑定多个条件，一个ReentrantLock对象可以同时绑定对个对象。
private ReentrantLock lock = new ReentrantLock();
public void run() {
lock.lock();
try{
for(int i=0;i<5;i++){
System.out.println(Thread.currentThread().getName()+":"+i);
}
}finally{
lock.unlock();
}
}
Maven package
依赖放外面
- 使用
dependency插件将依赖文件copy到target目录的/lib文件夹下 - 在
jar插件中指定:-
main的位置 - 外面的依赖文件位置
./lib/, 注意是相对目录
-
- 依赖文件并不会打包在jar文件中, 而是存在于同级目录的
lib文件夹下
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<id>copy</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>./lib/</classpathPrefix>
<mainClass>club.banyuan.NewTask</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
依赖放到jar文件中
- 注意下面的
descriptorRef只能是jar-with-dependencies - 运行
mvn package后会生成带依赖的jar包
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<archive>
<manifest>
<mainClass>
club.banyuan.NewTask
</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
安全
Spring Security原理
JWT原理
动态URL权限
OAuth原理
数据库
底层结构
树
BST
二叉搜索树,可能不平衡,因此查找的速度有可能不是O(log(n)).
AVL
自平衡二叉搜索树
AVL树的高度必须是log(n),以此来保证搜索的时间复杂度为O(log(n)).即任意节点的左子树和右子树高度差不会超过1.
通过左旋和右旋来实现树的平衡.
插入的示例:
缺点: 因为每次插入操作都需要维护数的平衡性,因此操作会比较耗时. 适用于插入和删除操作较少,而搜索较多的情况.
红黑树
自平衡二叉搜索树, 非严格平衡. 满足如下条件:
- Every node has a color either red or black.
每个node非红即黑
- Root of tree is always black.
根节点必须是黑色
- There are no two adjacent red nodes (A red node cannot have a red parent or red child).
不能有相邻节点的颜色都为红色
- Every path from a node (including root) to any of its descendant NULL node has the same number of black nodes.
任意节点到它的叶子节点的路径中包含的黑节点数目相同
虽然可能出现某些节点的平衡因子(左子树和右子树的高度差)大于1, 也即数的高度可能大于log_2(n); 但不会超过2*log_2(n+1).
高效的插入和删除(时间复杂度都为O(log n))使得其广泛引用.
例如HaspMap中的TreeNode.
B树
为了将数据有效的存储在硬盘上,同时减小搜索的时间:
- 从二叉树到2-3数到B-树:
- B-Tree的层次结构:
- Root node(根节点)
This has no parents and is the top of the tree.
- Leaf nodes(叶节点)
These are the bottom layer nodes that have no child nodes.
- Internal nodes(内部节点)
These are all other nodes, connecting root with leaves. There is usually more than one level of internal nodes.
- B-Tree规则
- 排序方式：所有节点关键字是按递增次序排列，并遵循左小右大原则；
- 子节点数：非叶节点的子节点数>1，且<=M ，且M>=2，空树除外（注：M阶代表一个树节点最多有多少个查找路径，M=M路,当M=2则是2叉树,M=3则是3叉）；
- 关键字数：枝节点的关键字数量大于等于ceil(m/2)-1个且小于等于M-1个（注：ceil()是个朝正无穷方向取整的函数 如ceil(1.1)结果为2);
- 所有叶子节点均在同一层、叶子节点除了包含了关键字和关键字记录的指针外也有指向其子节点的指针只不过其指针地址都为null对应下图最后一层节点的空格子;
B-Tree示例:
B+树
B+-TREES We’re using the term B-Tree as an umbrella for a family of data structures that share all or most of the mentioned properties. A more precise name for the described data structure is B+-Tree. [KNUTH98] refers to trees with a high fanout as multiway trees.
B-Trees allow storing values on any level: in root, internal, and leaf nodes. B+-Trees store values only in leaf nodes. Internal nodes store only separator keys used to guide the search algorithm to the associated value stored on the leaf level.
Since values in B+-Trees are stored only on the leaf level, all operations (inserting, updating, removing, and retrieving data records) affect only leaf nodes and propagate to higher levels only during splits and merges.
B+-Trees became widespread, and we refer to them as B-Trees, similar to other literature the subject. For example, in [GRAEFE11] B+-Trees are referred to as a default design, and MySQL InnoDB refers to its B+-Tree implementation as B-tree.
事务
并发控制的基本单位.
事务是一个序列操作，其中的操作要么都执行，要么都不执行，它是一个不可分割的工作单位.
事务拥有四个重要的特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），人们习惯称之为 ACID 特性。
ACID
原子性（Atomicity）
事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。例如，如果一个事务需要新增 100 条记录，但是在新增了 10 条记录之后就失败了，那么数据库将回滚对这 10 条新增的记录。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
一致性（Consistency）
指事务将数据库从一种状态转变为另一种一致的的状态。事务开始前和结束后，数据库的完整性约束没有被破坏。例如工号带有唯一属性，如果经过一个修改工号的事务后，工号变的非唯一了，则表明一致性遭到了破坏。
隔离性（Isolation）
要求每个读写事务的对象对其他事务的操作对象能互相分离，即该事务提交前对其他事务不可见。 也可以理解为多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。这指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。例如一个用户在更新自己的个人信息的同时，是不能看到系统管理员也在更新该用户的个人信息（此时更新事务还未提交）。
注：MySQL 通过锁机制来保证事务的隔离性。
持久性（Durability）
事务一旦提交，则其结果就是永久性的。即使发生宕机的故障，数据库也能将数据恢复，也就是说事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。这只是从事务本身的角度来保证，排除 RDBMS（关系型数据库管理系统，例如 Oracle、MySQL 等）本身发生的故障。
注：MySQL 使用 redo log 来保证事务的持久性。
MySQL事务的隔离级别
READ UNCOMMITTED（读未提交）
该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为 脏读 。
- 准备
SET @@session.transaction_isolation = 'READ-UNCOMMITTED';
create database test;
use test;
create table test(id int primary key);
insert into test(id) values(1);
- 终端1写
begin;
update test set id = 2 where id = 1;
select * from test; -- 此时看到一条ID为2的记录
- 终端2读
use test;
begin;
select * from test; -- 此时看到一条 ID 为 2 的记录
最后一步读取到了 mysql 终端 1 中未提交的事务（没有 commit 提交动作），即产生了脏读，大部分业务场景都不允许脏读出现，但是此隔离级别下数据库的并发是最好的。
READ COMMITTED（读提交）
一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为 不可重复读问题 ，Oracle 和 SQL Server 的默认隔离级别。
准备两个终端，在此命名为 mysql 终端 1 和 mysql 终端 2，再准备一张测试表 test，写入一条测试数据并调整隔离级别为 READ COMMITTED，任意一个终端执行即可。
SET @@session.transaction_isolation = 'READ-COMMITTED';
create database test;
use test;
create table test(id int primary key);
insert into test(id) values(1);
- 登录 mysql 终端 1，开启一个事务，将 ID 为 1 的记录更新为 2，并确认记录数变更过来。
begin;
update test set id = 2 where id = 1;
select * from test; -- 此时看到一条记录为 2
- 登录 mysql 终端 2，开启一个事务后，查看表中的数据。
use test;
begin;
select * from test; -- 此时看一条 ID 为 1 的记录
- 登录 mysql 终端 1，提交事务。
select * from test; -- 此时看到一条 ID 为 2 的记录
commit;
- 切换到 mysql 终端 2。
select * from test; -- 此时看到一条 ID 为 2 的记录
mysql 终端 2 在开启了一个事务之后，在第一次读取 test 表（此时 mysql 终端 1 的事务还未提交）时 ID 为 1，在第二次读取 test 表（此时 mysql 终端 1 的事务已经提交）时 ID 已经变为 2，说明在此隔离级别下已经读取到已提交的事务。
REPEATABLE READ（可重复读）
该隔离级别是 MySQL 默认的隔离级别，在同一个事务里，select 的结果是事务开始时时间点的状态，因此，同样的 select 操作读到的结果会是一致的，但是，会有幻读现象。MySQL 的 InnoDB 引擎可以通过 next-key locks 机制来避免 幻读 (以select的结果支撑之后的操作,而select的结果并不可靠) 。
SET @@session.transaction_isolation = 'REPEATABLE-READ';
create database test;
use test;
create table test(id int primary key,name varchar(20));
- 登录 mysql 终端 1，开启一个事务。
begin; select * from test; -- 无记录 - 登录 mysql 终端 2，开启一个事务。
begin;
select * from test; -- 无记录
- 切换到 mysql 终端 1，增加一条记录并提交。
insert into test(id,name) values(1,'a');
commit;
- 切换到 msyql 终端 2
select * from test; --此时查询还是无记录
通过这一步可以证明，在该隔离级别下已经读取不到别的已提交的事务，如果想看到 mysql 终端 1 提交的事务，在 mysql 终端 2 将当前事务提交后再次查询就可以读取到 mysql 终端 1 提交的事务。我们接着实验，看看在该隔离级别下是否会存在别的问题。
- 此时接着在 mysql 终端 2 插入一条数据。
insert into test(id,name) values(1,'b'); -- 此时报主键冲突的错误
也许到这里您心里可能会有疑问，明明在第 5 步没有数据，为什么在这里会报错呢？其实这就是该隔离级别下可能产生的问题，MySQL 称之为 幻读 。注意这里强调的是 MySQL 数据库，Oracle 数据库对于幻读的定义可能有所不同。
SERIALIZABLE（序列化）
在该隔离级别下事务都是串行顺序执行的，MySQL 数据库的 InnoDB 引擎会给读操作隐式加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。
SET @@session.transaction_isolation = 'SERIALIZABLE';
create database test;
use test;
create table test(id int primary key);
- 登录 mysql 终端 1，开启一个事务，并写入一条数据。
begin;
insert into test(id) values(1);
- 登录 mysql 终端 2，开启一个事务。
begin;
select * from test; -- 此时会一直卡住
- 立马切换到 mysql 终端 1,提交事务。
commit;
- 一旦事务提交，msyql 终端 2 会立马返回 ID 为 1 的记录，否则会一直卡住，直到超时，其中超时参数是由 innodb_lock_wait_timeout 控制。
由于每条 select 语句都会加锁，所以该隔离级别的数据库并发能力最弱，但是有些资料表明该结论也不一定对，如果感兴趣，您可以自行做个压力测试。
各个隔离级别下产生的一些问题
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
| 读未提交 | 可以出现 | 可以出现 | 可以出现 |
| 读提交 | 不允许出现 | 可以出现 | 可以出现 |
| 可重复读 | 不允许出现 | 不允许出现 | 可以出现 |
| 序列化 | 不允许出现 | 不允许出现 | 不允许出现 |
Spring事务的传播行为
REQUIRED
缺省行为, 当前方法如果不存在于事务中,则创建新的事务,否则使用已有的事务, 总之需要事务.
SUPPORTS
检查是否已有事务,如果存在事务则在事务中执行, 否则不启用事务. 仅仅表示支持而已.
MANDATORY
已有事务则放到事务中执行, 否则抛出异常… 强制该方法需要在已有的事务中执行
NEVER
如果在已有的事务中执行该方法, 则抛出异常… 总之就是这个方法不能在事务中执行
NOT_SUPPORTED
如果已有事务则暂停该事务, 以非事务的方式执行该方法, 再恢复事务… 也就是不支持在事务中运行该方法
REQUIRES_NEW
如果已有事务则暂停已有事务, 新开启一个事务执行该方法, 运行完毕再恢复被暂停的事务
NESTED
- 如果没有事务, 则创建一个事务.
- 如果已有事务, 则为已有事务创建一个save point, 再执行该方法. 如果该方法中抛出异常, 则回滚到该方法执行前的状态.
锁
- 读锁 共享锁，加锁后其他session只能读不能写
- 写锁 互斥锁，加锁后其他session不能读也不能写
- 行锁 通过Index访问数据会为该Index的行加上锁
- 表锁 对整张表加上锁
Index(索引)
Index原则
查询优化
插入后获取自增ID
新增blog如何获取到 insert 后的id:
public void insertBlog(Blog blog);
<insert id="insertBlog" parameterType="club.banyuan.blog.bean.Blog">
<selectKey resultType="java.lang.Integer" order="AFTER" keyProperty="id">
SELECT LAST_INSERT_ID()
</selectKey>
INSERT INTO blog (title, content, user_id)
VALUES
(#{title}, #{content}, #{author.id})
</insert>
- 在
<insert>标签中使用<selectKey>标签来获取新增数据后对应的id, 注意对于自增id需要使用 ~order=”AFTER”~ 表示插入完成后, 将id写回对象. -
SELECT LAST_INSERT_ID()选择最近插入table的id值- LAST_INSERT_ID()的值是由MySQL server来维护的，而且是为每条连接维护独立的值，也即，某条连接调用LAST_INSERT_ID()获取到的值是这条连接最近一次INSERT操作执行后的自增值，该值不会被其它连接的SQL语句所影响。这个行为保证了不同的连接能正确地获取到它最近一次INSERT SQL执行所插入的行的自增值，也就是说，LAST_INSERT_ID()的值不需要通过加锁或事务机制来保证其在多连接场景下的正确性。
- 假如你使用 INSERT IGNORE而记录被忽略，则AUTO_INCREMENT 计数器不会增量，而 LAST_INSERT_ID() 返回0, 这反映出没有插入任何记录。
- 使用一条INSERT语句同时插入多个行的数据时， LAST_INSERT_ID() 只返回插入的第一行数据时产生的值。
多表查询
Java对象
public class Blog implements Serializable {
Integer id;
String title;
String content;
Date createdTime;
User author;
List<Comment> comments;
}
public class Comment {
Integer id;
String content;
Date createdTime;
User commenter;
Integer blogId;
}
public class User {
Integer id;
String password;
String name;
String email;
}
多表查询及Mybatis映射
一个Blog对象对应一个User对象(作者), 一个Blog对象对应多个Comment对象, 而一个Comment对象对应于一个评论者(Commenter).
所以我们的Mybits 查询会稍微复杂些:
- 多表查询
<select id="getBlogById" resultMap="blogDetailMap" parameterType="java.lang.Integer">
select blog.id, blog.title, blog.content, blog.created_time, blog.user_id,
user.name as user_name, user.password as user_password, user.email as user_email,
comment.id as comment_id, comment.content as comment_content, comment.created_time as comment_created_time, comment.blog_id as comment_blog_id,
commenter.id as comment_commenter_id, commenter.name as comment_commenter_name, commenter.password as comment_commenter_password, commenter.email as comment_commenter_email
from (blog left join user on blog.user_id = user.id left join comment on blog.id = comment.blog_id left join user as commenter on comment.user_id = commenter.id)
where blog.id = #{id}
</select>
- 这里最好为每张表的字段都加上一个前缀, 以便后面映射的时候使用
columnPrefix统一去除 -
#{}用来引入变量, 注意不要使用${}, 因为前者会通过SQL预编译, 生成机器码；而后者是字符串替换, 有SQL注入的风险 -
left join,right join,join,outer join要分清- ResultMap
数据库查询得到的是一张表, 一行或多行, 每一列都有一个名字, 如下所示:
+----+---------+---------------------+---------------------+---------+-----------+---------------+------------+------------+----------------------------------------------+----------------------+-----------------+----------------------+------------------------+----------------------------+-------------------------+ | id | title | content | created_time | user_id | user_name | user_password | user_email | comment_id | comment_content | comment_created_time | comment_blog_id | comment_commenter_id | comment_commenter_name | comment_commenter_password | comment_commenter_email | +----+---------+---------------------+---------------------+---------+-----------+---------------+------------+------------+----------------------------------------------+----------------------+-----------------+----------------------+------------------------+----------------------------+-------------------------+ | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 1 | 评论1 | 2020-01-01 17:06:32 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 2 | comment2 | 2020-01-06 13:46:59 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 3 | comment 3 | 2020-01-13 18:19:51 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 4 | comment 4 | 2020-01-13 18:20:07 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 5 | 用户2对应第一个blog的第一条评论 | 2020-01-15 09:16:22 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 6 | 用户1对于第一个blog的第一条评论 | 2020-01-15 09:16:22 | 1 | 1 | 王二 | asdf | er@er.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 7 | 用户2对应第一个blog的第一条评论 | 2020-01-15 10:44:03 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 8 | 用户1对于第一个blog的第一条评论 | 2020-01-15 10:44:03 | 1 | 1 | 王二 | asdf | er@er.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 9 | aaaaaaaaaaa | 2020-01-16 13:03:29 | 1 | 1 | 王二 | asdf | er@er.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 10 | ccccccccc | 2020-01-16 13:04:10 | 1 | 1 | 王二 | asdf | er@er.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 12 | xxxxxxxxxxx | 2020-01-16 15:38:06 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 13 | aaaaaaaaa | 2020-01-17 13:11:16 | 1 | 2 | aa | asdf | a@a.com | | 1 | 标题1 | 内容1111111111111 | 2020-01-01 17:03:35 | 1 | 王二 | asdf | er@er.com | 14 | bbbbbbbbbbb | 2020-01-17 13:33:28 | 1 | 1 | 王二 | asdf | er@er.com | +----+---------+---------------------+---------------------+---------+-----------+---------------+------------+------------+----------------------------------------------+----------------------+-----------------+----------------------+------------------------+----------------------------+-------------------------+
这里查询出来的其实是一个Blog的对象, 因为有多条评论, 所以出来了多行的记录. 我们需要:
- 将博客作者映射出来成为1个User对象
<resultMap id="userMap" type="club.banyuan.bean.User" autoMapping="true"> <id property="id" column="id"></id> </resultMap>- 使用
association来表示一对一的映射 -
autoMapping设置为true表示从MySQL中select出的表字段自动映射到该对象相同名称的成员变量上. -
<id property="id" column="id"></id>表示以数据库中的id列为主键, 相同的id行为同一个java对象,property对应于java中的成员名称.
- 使用
- 将每条评论映射为Comment对象
<collection property="comments" ofType="club.banyuan.bean.Comment" autoMapping="true" columnPrefix="comment_"> <id property="id" column="comment_id"></id> <association property="commenter" resultMap="userMap" autoMapping="true" columnPrefix="commenter_"> <id property="id" column="comment_commenter_id"></id> </association> </collection>- 使用
collection表示一对多的映射, 会生成List<>. 需要使用ofType来表示每一行对应的Java对象. -
columnPrefix列前缀, 用来截断SQL返回表的field名称. - 中间凡是涉及到
column的属性都填写数据库返回表项filed的全称 - 这是一个
collection中又包含了association的示范, 注意第二个 ~columenPrefix=”commenter_”~ 是在第一个前缀之后的前缀, 因此不要包含上个前缀, 否则无法自动映射成功.
- 使用
- 组合成完整的映射
<resultMap id="blogDetailMap" type="club.banyuan.bean.Blog" autoMapping="true"> <id property="id" column="id"></id> <association property="author" resultMap="userMap" autoMapping="true" columnPrefix="user_"> <id property="id" column="user_id"></id> </association> <collection property="comments" ofType="club.banyuan.bean.Comment" autoMapping="true" columnPrefix="comment_"> <id property="id" column="comment_id"></id> <association property="commenter" resultMap="userMap" autoMapping="true" columnPrefix="commenter_"> <id property="id" column="comment_commenter_id"></id> </association> </collection> </resultMap>
提取表、派生表、Derived Table
有时需要从某些select的结果中再做筛选和组合， 可以将select的结果表示为一张有名字的表。
SELECT column_list FROM (SELECT column_list FROM table_1) derived_table_name; WHERE derived_table_name.c1 > 0;
例如可以将第一次选择的结果和其他表项做left join
select * from (select * from blog order by id limit 10 offset 10) B left join comment on B.id = comment.blog_id;
VIEW
CREATE VIEW page AS select * from blog order by id limit 10 offset 10;
select * from page left join comment on page.id = comment.commenter.id;
Spring-RabbitMQ
为什么使用消息队列
WebServer的最主要作用是尽快处理用户请求, 而对于一些耗时较长的任务, 我们需要将它们提取出来, 使用其他资源(服务器/进程)来处理, 例如PDF转换, 图片转换, 视频转换, 上传下载等, 收发邮件, 收发短信等. 这也就是异步任务的主要产生原因.
AMQP
Advanced Message Queuing Protocol
组成部分
- Producers
- Broker
- Consumers
好处
消息解耦, 良好的可扩展性
RabbitMQ组件
场景
单收(Direct)
所有的都收(Fanout)
指定那些人收(Topic)
如何确保消息被消费成功(ACK)
https://www.cloudamqp.com/blog/2015-09-03-part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html
https://www.cnblogs.com/luxiaoxun/p/3918054.html
死信队列实现超时未支付订单处理
https://www.codetd.com/article/9845211
注意: 仅是针对未支付订单的处理, 订单支付(例如微信支付之类)成功后应该会向你的APP发送POST消息, 应该及时处理这个消息, 刷新订单状态.
这个场景也可使用Redis来实现
https://www.jianshu.com/p/f5f81b2b2005
编码
增加依赖 - pom.xml
<!-- rabbitmq -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
配置RabbitMq
- Producer
- Exchange
- Queue
- Binding
public class RabbitMqConfig { static final String topicExchangeName = "spring-boot-exchange"; static final String queueName = "spring-boot"; public static String getTopicExchangeName() { return topicExchangeName; } public static String getQueueName() { return queueName; } @Bean Queue queue() { return new Queue(queueName); } @Bean TopicExchange exchange() { return new TopicExchange(topicExchangeName); } @Bean Binding binding(Queue queue, TopicExchange exchange) { return BindingBuilder.bind(queue).to(exchange).with("foo.bar.#"); } }- Consumer
- Queue
- Receiver
无需配置,直接在接收处理的函数上使用
@RabbitListener注解即可.
Producer
使用RabbitMqTemplate进行消息的发送
@Autowired
private RabbitMessagingTemplate template;
@Autowired
private Gson gson;
private Logger logger = LoggerFactory.getLogger(this.getClass());
public void sendTestMail(String receiver, String subject, String content) {
MailMessage message = new MailMessage(subject, content, receiver);
template.convertAndSend(RabbitMqConfig.getTopicExchangeName(), "foo.bar.baz", gson.toJson(message));
logger.info("send msg" + message);
}
Consumer
直接在接收处理的函数上使用 @RabbitListener 注解.
@Service
public class Receiver {
@Autowired
private MailService mailService;
@Autowired
private Gson gson;
@RabbitListener(queues = "spring-boot")
public void receiveMessage(String mail, Channel channel, Message message) throws InterruptedException, IOException {
// 三个参数, 第一个表示发送方发送的消息, 第二个为channel,发送ack的时候用,第三个message的属性中包含该消息的tag,也是用于ACK
MailMessage mailBody = gson.fromJson(mail, MailMessage.class);
for (int i = 0; i < 10; i++) {
System.out.println(i);
Thread.sleep(1000);
}
mailService.sendMail(mailBody.getReceiver(), mailBody.getSubject(), mailBody.getContent());
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
System.out.println("send ack");
}
}
关键问题
接收方不能反序列化
- 原因
直接通过 Serializable 在RabbtitMQ中传递对象需要发送方和接收方对于该对象的目录结构和定义完全一致
- 解决方法
- 使用Gson转为JSON进行传递
- 包含Gson的依赖
- 直接
@Autowired Gson gson, 然后使用gson.fromJson() gson.toJson()
手动ACK的实现
- 在Spring的配置中配置手动ACK
spring.rabbitmq.listener.simple.acknowledge-mode=manual
- 在接收完成任务后发送ACK
@RabbitListener(queues = "spring-boot")
public void receiveMessage(String mail, Channel channel, Message message) throws InterruptedException, IOException {
MailMessage mailBody = gson.fromJson(mail, MailMessage.class);
for (int i = 0; i < 10; i++) {
System.out.println(i);
Thread.sleep(1000);
}
mailService.sendMail(mailBody.getReceiver(), mailBody.getSubject(), mailBody.getContent());
// 调用channel对象的basicAck方法发送ACK, 注意第二个参数的false是指只回复当前这个消息的ACK
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
System.out.println("send ack");
}
缓存
key的规划
如何触发老化/刷新
全文检索
ES的机制
数据同步
容器
微服务
面试
讲好一个故事
- 业务流程（接口）
- 技术点
- 重难点、如何解决
举报
请认真填写举报原因，尽可能描述详细。
请选择举报类型
误判申诉
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化