三大框架的工作原理

struts1的工作原理图：

1.初始化：struts框架的总控制器ActionServlet是一个Servlet，它在web.xml中配置成自动启动的Servlet，在启动时总控制器会读取配置文件(struts-config.xml)的配置信息，为struts中不同的模块初始化相应的对象。(面向对象思想)

2.发送请求：用户提交表单或通过URL向WEB服务器提交请求，请求的数据用HTTP协议传给web服务器。

3.form填充：struts的总控制器ActionServlet在用户提交请求时将数据放到对应的form对象中的成员变量中。

4.派发请求：控制器根据配置信息对象ActionConfig将请求派发到具体的Action，对应的formBean一并传给这个Action中的excute()方法。

5.处理业务：Action一般只包含一个excute()方法，它负责执行相应的业务逻辑(调用其它的业务模块)完毕后返回一个ActionForward对象。服务器通过ActionForward对象进行转发工作。

6.返回响应：Action将业务处理的不同结果返回一个目标响应对象给总控制器。

7.查找响应：总控制器根据Action处理业务返回的目标响应对象，找到对应的资源对象，一般情况下为jsp页面。

8.响应用户：目标响应对象将结果传递给资源对象，将结果展现给用户。

AOP原理篇:为什么用AOP?

1.为了方便，看一个国外很有名的大师说，编程的人都是“懒人”，因为他把自己做的事情都让程序做了。用了aop能让你少写很多代码，这点就够充分了吧。

2.就是为了更清晰的逻辑，可以让你的业务逻辑去关注自己本身的业务，而不去想一些其他的事情，这些其他的事情包括：安全，事物，日志等。AOP原理：spring用代理类包裹切面，把他们织入到Spring管理的bean中。也就是说代理类伪装成目标类，它会截取对目标类中方法的调用，让调用者对目标类的调用都先变成调用伪装类，伪装类中就先执行了切面，再把调用转发给真正的目标bean。

现在可以自己想一想，怎么搞出来这个伪装类，才不会被调用者发现（过JVM的检查，JAVA是强类型检查，哪里都要检查类型）。

1.实现和目标类相同的接口，我也实现和你一样的接口，反正上层都是接口级别的调用，这样我就伪装成了和目标类一样的类（实现了同一接口，咱是兄弟了），也就逃过了类型检查，到java运行期的时候，利用多态的后期绑定（所以spring采用运行时），伪装类（代理类）就变成了接口的真正实现，而他里面包裹了真实的那个目标类，最后实现具体功能的还是目标类，只不过伪装类在之前干了点事

这就好比，一个人让你办件事，每次这个时候，你弟弟就会先出来，当然他分不出来了，以为是你，你这个弟弟虽然办不了这事，但是他知道你能办，所以就答应下来了，并且收了点礼物（写日志），收完礼物了，给把事给人家办了啊，所以你弟弟又找你这个哥哥来了，最后把这是办了的还是你自己。但是你自己并不知道你弟弟已经收礼物了，你只是专心把这件事情做好。

顺着这个思路想，要是本身这个类就没实现一个接口呢，你怎么伪装我，我就压根没有机会让你搞出这个双胞胎的弟弟，那么就用第2种代理方式，创建一个目标类的子类，生个儿子，让儿子伪装我。 2.生成子类调用，这次用子类来做为伪装类，当然这样也能逃过JVM的强类型检查，我继承的吗，当然查不出来了，子类重写了目标类的所有方法，当然在这些重写的方法中，不仅实现了目标类的功能，还在这些功能之前，实现了一些其他的（写日志，安全检查，事物等）。

这次的对比就是，儿子先从爸爸那把本事都学会了，所有人都找儿子办事情，但是儿子每次办和爸爸同样的事之前，都要收点小礼物（写日志），然后才去办真正的事。当然爸爸是不知道儿子这么干的了。这里就有件事情要说，某些本事是爸爸独有的(final的)，儿子学不了，学不了就办不了这件事，办不了这个事情，自然就不能收人家礼了。

前一种兄弟模式，spring会使用JDK的https://www.360docs.net/doc/681287314.html,ng.reflect.Proxy类，它允许Spring 动态生成一个新类来实现必要的接口，织入通知，并且把对这些接口的任何调用都转发到目标类。

后一种父子模式，spring使用CGLIB库生成目标类的一个子类，在创建这个子类的时候，spring织入通知，并且把对这个子类的调用委托到目标类。

相比之下，还是兄弟模式好些，他能更好的实现松耦合，尤其在今天都高喊着面向接口编程的情况下，父子模式只是在没有实现接口的时候，也能织入通知，应当做一种例外。

Hibernate原理篇:

Hibernate是采用ORM模式实现数据持久层的java组件。它提供了高效的、强大的将java对象进行数据持久化操作的服务。利用hibernate，开发人员可以按照java对象的结果进行持久层的开发，并可以完成java对象和关系型数据库之间的转换和操作。hibernate的工作原理：

1.创建Configeration实例

根据它的构造方法将指定的配置信息(默认hibernate.cfg.xml)读到内存。一个Configeration 实例代表Hibernate 所有Java类到Sql数据库映射的集合。

2.创建SessionFactory实例

当使用Configeration实例创建了SessionFactory实例后，把Configeration 对象中的所有配置信息拷贝到SessionFactory的缓存中。SessionFactory的实例代表一个数据库存储源，创建后不在与Configeration 对象关联。SessionFactory是线程安全的，通常情况下，一个应用程序只有一个SessionFactory的实例。

3.创建Session实例

通过SessionFactory创建Session实例，session不是线程安全的，每个使用者应该用SessionFactory实例获得自己的session实例。获得session实例后就可以利用session的各种方法对对象进行持久化操作了。

4.创建Transaction事务

通过Session的beginTransaction()方法可以得到一个对象的实例。主要用于管理实务。一个事物对象可能会包括多个对数据库进行的操作。

hibernate的缓存：为了提高系统性能，hibernate也使用了缓存机制。在hibernate框架中，主要包含两个方面的缓存，一级缓存和二级缓存。hibernate缓存的作用主要表现在以下两个方面： 1 通过主键(ID)加载数据的时候 2 延迟加载中。

一级缓存：hibernate的一级缓存是由session提供的，因此它只存在session的生命周期中。也就是说session关闭的时候该session所管理的一级缓存也随之被清除。hibernate的一级缓存是session所内置的，不能被卸载，也不能进行任何配置。一级缓存采用的是Key-Value的MAP方式来实现的。在缓存实体对象时，对象的主关键字ID是MAP的Key，实体对象就是对象的值。所以说一级缓存是以实体对象为单位进行存储的。访问的时候使用的是主键关键字ID。一级缓存使用的是自动维护的功能。但可以通过session提供的手动方法对一级缓存的管理进行手动干预。evict()方法用于将某个对象从session的一级缓存中清除。clear()方法用于将session缓存中的方法全部清除。

二级缓存：SessionFactory提供的缓存机制可以将缓存分为内置缓存和外置缓存。内置缓存存放了映射文件中数据的副本和预定义SQL语句。SessionFactory的外置缓存就是我们的二级缓存。它是一个可配置的插件，默认情况下SessionFactory不会启用这个插件，外置缓存的数据是数据库数据的副本。外置缓存的介质可以是内存或者硬盘。二级缓存的实现原理与一级缓存是一样的。也是通过Key-Value的Map来实现对对象的缓存。二级缓存是作用在SessionFactory范围内的。因此它比一级缓存的范围更广。它可被所有的Session对象所共享。需要注意的是放入缓存中的数据不能有第三方的应用对数据进行修改。

Hibernate实体对象的生命周期

实体对象的生命周期主要存在三种不同状态：瞬态、持久态和游离态。

瞬态：表示该实体对象在内存中是自由自在的。与数据库中的数据没有任何关系。与session 没有任何关系，也就是没有通过session的实例对其任何持久化的操作。

持久态：该实体对象处于hibernate框架所管理的状态。也就是说这个对象是与session的实体对象相关的。处于持久态的实体对象的特征就是其所作的任何的变更操作都将被Hibernate持久化到数据库中。我们可以说持久态的周期与其对应的session的周期息息相关的。hibernate会依据处于持久态的实体对象的属性变化而改变数据库中的对应记录。

游离态：处于持久态的实体对象，当不再与其对应的session对象相关联时，就处于游离态。spring IOC(控制反转)浅析

简单的来说，spring是一个轻量级的开源的控制反转(IOC)和面向切面(AOP)的容器框架。主要是为了解决企业应用程序开发中的复杂性而创建的。它的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 J2EE 应用程序开发提供集成的框架(struts、hibernate等)。Spring由 7 个定义良好的模块组成，Spring 模块构建在核心容器之上(就是我们所说的IOC容器)，核心容器定义了创建、配置和管理 bean 的方式。组成Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。spring的目标是实现一个全方位的整合框架，在spring框架下实现多个子框架的组合，这些子框架之间可以相互独立，也可以使用其他框架方案加以替代。

IOC：控制反转，它是不是什么技术，它是一种设计模式。所谓控制反转就是由容器控制程序间的关系，而不是传统实现中，由编程代码直接操控。说白了就是由容器控制对象间的依赖关系。

DI：Dependency Injection 依赖注入，即组件(对象)之间的依赖关系由容器在运行期间决定。其实依赖注入和控制反转是对同一概念的不同描述。

Spring通过这种控制反转（IoC）的设计模式促进了松耦合。当应用了IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。我们可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

(自己理解的白话)其实控制反转就是不需要我们手动new一个对象了，它把我们所要实例化的对象都写在了配置文件xml中了，一般这个类都是我们应用的业务类。框架内部已经将xml中配置的类自动实例化成对象，当我们调用某个类A，并且这个类中存在另一个类B 时，我们就说A依赖于B,容器就会将B对象注入到A类中，大多数情况下都是通过A类中的setB()方法注入进来的。以前是由类中的代码查找类并new对象，现在是xml文件控制的对象的生成，控制权由程序代码转移到了xml文件中。这样做还是有好处的，假如在A

中需要5个对象，那么A类中就会new5个对象，不管以后A中用不用到这5个类，只要用到A类，就会把这5个类全部new出来。如果我们在xml文件中定义类的话，当类需要用到其中的三个类时，就会用对应的set类()方法将对象注入进来，不用的就不注入进来，由此看来，第一个方法时将类A和5个类紧紧联系起来，不管用不用到5个类都new一下，真浪费，而第二个方法是第一个类你需要我得时候我就注入进来被你用，你不需要就和我没关系。这样类A和其中的5个类是分别独立的互不干预，当有关系的时候，容器自动注入关系。没关系的时候，你是老大，我也是大哥！

Struts2的工作原理篇:

struts2并不是一个陌生的web框架，它是以Webwork的设计思想为核心，吸收struts1的优点，可以说struts2是struts1和Webwork结合的产物。

struts2 的工作原理图：

一个请求在Struts2框架中的处理分为以下几个步骤：

1.客户端发出一个指向servlet容器的请求(tomcat)；

2.这个请求会经过图中的几个过滤器，最后会到达FilterDispatcher过滤器。

3.过滤器FilterDispatcher是struts2框架的心脏，在处理用户请求时，它和请求一起相互配合访问struts2的底层框架结构。在web容器启动时，struts2框架会自动加载配置文件里相关参数，并转换成相应的类。如：ConfigurationManager、ActionMapper和ObjectFactory。ConfigurationManager 存有配置文件的一些基本信息，ActionMapper存有action的配置信息。在请求过程中所有的对象（Action，Results， Interceptors，等）都是通过ObjectFactory来创建的。过滤器会通过询问ActionMapper类来查找请求中需要用到的Action。

4.如果找到需要调用的Action，过滤器会把请求的处理交给ActionProxy。ActionProxy为Action的代理对象。ActionProxy通过ConfigurationManager询问框架的配置文件，找到需要调用的Action类。

5.ActionProxy创建一个ActionInvocation的实例。ActionInvocation在ActionProxy层之下，它表示了Action的执行状态,或者说它控制的Action的执行步骤。它持有Action

实例和所有的Interceptor。

6.ActionInvocation实例使用命名模式来调用，1. ActionInvocation初始化时，根据配置，加载Action相关的所有Interceptor。2. 通过ActionInvocation.invoke方法调用Action 实现时，执行Interceptor。在调用Action的过程前后，涉及到相关拦截器(intercepetor)的调用。

7. 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。