ssh总结

1. struts

1.1 struts运行机制（原理）及其为什么要使用

 

struts工作原理

1）客户端发出一个HttpServletRequest请求，到web服务器的struts2框架中

   首先经过ActionContextCleanUp过滤器，它主要对ActionContext域对象中的内容进行清理，例如：删除某些错误消息集合

   其它经过其它的一些过滤器，因为struts2框架可以与其它web层框架融合在一起工作，此时就得考虑得其它框架的工作特点，例如：

     SiteMesh框架，它主要对web页面进行布局等等

   最后，请求来到struts2框架的核心过滤器，StrutsPrepareAndExecuterFilter

2）创建ActionMapper对象

   》如果有不需要处理的资源，例如：html，jpg，或者是程序指定的不需要由struts2框架处理的URL路径，直接放行请求，struts2框架不进行处理

   》如果是需要处理的资源，继续交由struts2框架完成后继的操作

3）创建ActionProxy对象

4）创建ConfigurationManager对象

5）加载src/struts.xml程序员写的配置文件

   形成一个ActionMapping对象，该对象存有<action>标签的所有配置信息   

6）创建ActionInvocation对象

7）将创建好的ActionInvocation对象，交由struts框架中的默认拦载器栈，依次处理

   你将ActionInvocation对象，理解为过滤器链

   最好，通过反射调用程序员自己写的目标对象Action的业务方法

8）将Action返回的字符串，与真实的jsp页面对应起来，准备返回

9）返回时，还要依次经过逆序的过滤器链，整个拦载器执行过程中，ActionInvocation对象一直存在

10）如果上述操作，都完全正确，web服务器会创建HttpServletResponse对象，响应给客户端浏览器

为什么要用：

1. JSP、Servlet、JavaBean 技术的出现给我们构建强大的企业应用系统提供了可能。但用 这些技术构建的系统非常的繁乱。

2. 基于 Struts 开发的应用:

不需要再考虑公共问题，专心在业务实现上

 

1.2struts1与struts2的区别

1. Action： 
struts1必须继承一个抽象类；struts2是一个接口，甚至不使用任何接口。 
2. Action执行的控制： 
Struts1支持每一个模块有单独的Request Processors； 
Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。 
3. Action的安全性： 
struts1 Action资源必须是线程安全的或同步的； 
Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。
4.  Servlet依赖： 
Struts1 Action 依赖于Servlet API； 
Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。
如果需要，Struts2Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。 
5.  类型转换： 
Struts 1 ActionForm 属性通常都是String类型；
Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。
6.  页面值绑定： 
Struts1使用标准JSP机制把对象绑定到页面中来访问； 
Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和 对象绑定起来。 
ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面 

7.  表达式语言：
Struts1 整合了JSTL，因此使用JSTL EL。 
这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。 
Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL). 

8.  数据输入： 
struts1使用独立的actionForm来接收； 
Struts2 直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。
输入属性可能是有自己(子)属性的rich对象类型。 Action属性能够通过web页面上的taglibs访问。 
Struts2也支持ActionForm模式。 
rich对象类型，包括业务对象，能够用作输入/输出对象。 
这种ModelDriven特性简化了taglib对POJO输入对象的引用。 

9. 校验： 
Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。 
同一个类可以有不同的校验内容，但不能校验子对象。
Struts2支持通过validate方法和XWork校验框架来进行校验。
XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性。 
10.   测试： 
struts1依赖容器，因此不容易测试。 
Struts 2 Action可以通过初始化、设置属性、调用方法来测试， 
“依赖注入”支持也使测试更容易。

1.3struts优缺点

优点：

1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现.

2．有丰富的tag可以用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率

3. 页面导航使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。

4. 提供Exception处理机制 . 

5. 数据库链接池管理 

6. 支持I18N 

 

缺点

一、 转到展示层时，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcat这样的服务器，还必须重新启动服务器

 二、 Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。

三、  测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。 

四、  类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。

五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。 

六、  前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。 

七、  对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。 

八、  对Action 执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。 

九、对事件支持不够. 在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一个表单只能 对应一个事件，struts这种事件方式称为application event，application event和component event相比是一种粗粒度的事件

 

1.4 过滤器Filter和struts2拦截器的区别

1、拦截器是基于java反射机制的，而过滤器是基于函数回调的。
2、过滤器依赖于servlet容器，而拦截器不依赖于servlet容器。
3、拦截器只能对Action请求起作用，而过滤器则可以对几乎所有请求起作用。
4、拦截器可以访问Action上下文、值栈里的对象，而过滤器不能。

 

1.5struts2的核心控制器及其作用

Struts2框架的核心控制器：StrutsPrepareAndExecuteFilter。  

作用：  

 负责拦截由<url-pattern>/*</url-pattern>指定的所有用户请求，当用户请求到达时，该Filter会过滤用户的请求。默认情况下，如果用户请求的路径  

不带后缀或者后缀以.action结尾，这时请求将被转入struts2框架处理，否则struts2框架将略过该请求的处理。  

可以通过常量"struts.action.extension"修改action的后缀，如：  

<constant name="struts.action.extension" value="do"/>  

如果用户需要指定多个请求后缀，则多个后缀之间以英文逗号（,）隔开。

<constant name="struts.action.extension" value="do,go"/> 

 

1.6struts2的配置文件的加载顺序

struts2 core 核心包 org/apache/struts2/default.properties （定义Struts2 常量）

struts2 core 核心包 struts-default.xml （定义struts2 默认 package 、 拦截器、 结果类型）

struts2 plugin 插件包 struts-plugin.xml（定义struts2 插件的配置）

struts.xml （自定义struts2 配置文件）

struts.properties （自定义struts2 常量文件）

web.xml 中定义的struts2 常量

 

1.7 struts2 如何访问HttpServletRequest、HttpSession、ServletContext 三个域对象？

方案一：  

HttpServletRequest request =ServletActionContext.getRequest();  

HttpServletResponse response =ServletActionContext.getResponse();  

HttpSession  session=   request.getSession(); 

ServletContext servletContext=ServletActionContext.getServletContext();  

    

方案二：  

类 implements ServletRequestAware,ServletResponseAware，SessionAware，ServletContextAware  

注意：框架自动传入对应的域对象 

 

ps：ActionContext.getContext() 可以获得三个Map对象，间接对三个域对象中数据进行操作 

 

1.8 struts2如何对指定的方法进行验证？

1）validate()方法会校验action中所有与execute方法签名相同的方法；  

2）要校验指定的方法通过重写validateXxx()方法实现， validateXxx()只会校验action中方法名为Xxx的方法。其中Xxx的第一个字母要大写；  

3）当某个数据校验失败时，调用addFieldError()方法往系统的fieldErrors添加校验失败信息（为了使用addFieldError()方法，action可以继承ActionSupport）， 如果系统 的fieldErrors包含失败信息，struts2会将请求转发到名为input的result；  

4）在input视图中可以通过<s:fielderror/>显示失败信息。  

5）先执行validateXxxx()->validate()->如果出错了，会转发<result name="input"/>所指定的页面，如果不出错，会直接进行Action::execute()方法

 

1.9 struts2 默认能解决get和post乱码问题吗

不能。struts.i18n.encoding=UTF-8属性值只能解析POST提交下的乱码问题

get请求可以通过过滤器实现。

 

1.10 struts2优缺点

优点：

1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现.

2．有丰富的tag可以用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率

3. 页面导航使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。

4. 提供Exception处理机制 . 

5. 数据库链接池管理 

6. 支持I18N 

 

缺点   

一、 转到视图层时，需要配置forward，如果有十个视图层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcat这样的服务器，还必须重新启动服务器

 二、 Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。

三、  测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。 

四、  类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。

五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所以它摆脱不了Servlet容器。 

六、  前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。 

七、  对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。 

八、  对Action 执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。 

九、  对事件支持不够. 在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一个表单只能 对应一个事件，struts这种事件方式称为application event，application event和component event相比是一种粗粒度的事件

  

1.11值栈

 

生命周期及其原理

1）ValueStack贯穿整个 Action 的生命周期，保存在request域中，所以ValueStack和request的生命周期一样。当Struts2接受一个请求时，会迅速创建ActionContext，  

ValueStack，action。然后把action存放进ValueStack，所以action的实例变量可以被OGNL访问。 请求来的时候，action、ValueStack的生命开始，请求结束，action、    ValueStack的生命结束；  

2）action是多例的，和Servlet不一样，Servelt是单例的;

3）每个action的都有一个对应的值栈，值栈存放的数据类型是该action的实例，以及该action中的实例变量，Action对象默认保存在栈顶；  

4）ValueStack本质上就是一个ArrayList；  

5）关于ContextMap，Struts 会把下面这些映射压入 ContextMap 中：  

parameters  :   该 Map 中包含当前请求的请求参数  

request     :   该 Map 中包含当前 request 对象中的所有属性  session :该 Map 中包含当前 session 对象中的所有属性  

application :该 Map 中包含当前 application 对象中的所有属性  

attr:该 Map 按如下顺序来检索某个属性: request, session, application           

6）使用OGNL访问值栈的内容时，不需要#号，而访问request、session、application、attr时，需要加#号；  

7）注意： Struts2中，OGNL表达式需要配合Struts标签才可以使用。如：<s:property value="name"/>  

8）在struts2配置文件中引用ognl表达式 ,引用值栈的值 ，此时使用的"$"，而不是#或者%;  

 

1.12  ActionContext、ServletContext、pageContext区别？

1）ActionContext是当前的Action的上下文环境，通过ActionContext可以获取到request、session、ServletContext等与Action有关的对象的引用；  

2）ServletContext是域对象，一个web应用中只有一个ServletContext，生命周期伴随整个web应用；  

3）pageContext是JSP中的最重要的一个内置对象，可以通过pageContext获取其他域对象的应用，同时它是一个域对象，作用范围只针对当前页面，当前页面结束时，pageContext销毁，  生命周期是JSP四个域对象中最小的。  

 

1.13 result的type属性中有哪些结果类型？

dispatcher struts默认的结果类型，把控制权转发给应用程序里的某个资源不能把控制权转发给一个外部资源，若需要把控制权重定向到一个外部资源, 应该使用  

redirect  把响应重定向到另一个资源（包括一个外部资源）  

redirectAction 把响应重定向到另一个 Action  

freemarker、velocity、chain、httpheader、xslt、plainText、stream 

 

struts2-json-plugin 自定义 json 结果类型，用于返回json格式数据

 

1.14 拦截器的生命周期与工作过程

1）每个拦截器都是实现了Interceptor接口的 Java 类；  

2）init(): 该方法将在拦截器被创建后立即被调用, 它在拦截器的生命周期内只被调用一次. 可以在该方法中对相关资源进行必要的初始化；  

3）intercept(ActionInvocation invocation): 每拦截一个动作请求, 该方法就会被调用一次；  

4）destroy: 该方法将在拦截器被销毁之前被调用, 它在拦截器的生命周期内也只被调用一次；  

 

2.Hibernate

2.1：Hibernate 工作原理及为什么要用？

原理：

hibernate，通过对 jdbc 进行封装，对  java 类和 关系数据库进行 mapping（映射），实现了对关系数据库的面向对象方式的操作，改变了传统的 jdbc + sql 操作数据的方式，从而使开发人员可以花更多精力进行对象方面的开发

 

 

 

1.读取并解析配置文件hibernate.cfg.xml  

    Configuration config = new Configuration().configure();

2.读取并解析映射信息<mapping>，创建 SessionFactory  

    SessionFactory factory = config.buildSessionFactory();

3.打开 Sesssion

    Session session = factory.openSession();

4.创建事务 Transation

    Transaction transaction = session.beginTransaction();

5.持久化操作

    session.save();

6.提交事务

    transaction.commit();

7.关闭 Session

    session.close();

8.关闭 SesstionFactory

 

为什么要用：

1.对 JDBC 访问数据库的代码做了封装，大大简化了数据访问层繁琐的重复性代码。

2.Hibernate 是一个基于 JDBC 的主流持久化框架，是一个优秀的 ORM 实现。他很大程度 的简化 DAO 层的编码工作

3.hibernate使用Java反射机制，而不是字节码增强程序来实现透明性

4.hibernate 的性能非常好，因为它是个轻量级框架。映射的灵活性很出色。它支持各 种关系数据库，从一对一到多对多的各种复杂关系。

2.2 Hibernate的延迟加载及其懒加载问题

延迟加载机制是为了避免一些无谓的性能开销而提出来的，所谓延迟加载就是当在真正需要数据的时候，才真正执行数据加载操作。在 Hibernate2中提供了对实体对象的延迟加载以及对集合的延迟加载，另外在 Hibernate3 中还提供了对属性的延迟加载。

 

当Hibernate在查询数据的时候，数据并没有存储在内存中，只是使用Javassist为目标类创建子类代理对象，当程序真正对数据的进行操作时，代理对象的handler才去访问数据，加载对象存在于内存中，这就实现了延迟加载，它节省了服务器的内存开销，从而提高了服务器的性能。

 

² 在确定关联数据是必须时，可以配置 lazy=false 使用立即加载策略

² 使用OpenSessionInView 模式，在需要数据时，才去加载

² 在程序中，根据业务需要，手动Hibernate.initialize() 手动初始化延迟加载数据 

 

2.3Hibernate中类之间的关联关系

类与类之间的关系主要体现在表与表之间的关系进行操作，它们都是对对象进行操作，程序中把所有的表与类都映射在一起，它们通过配置文件中的many-to-one、one-to-many、many-to-many、（one-one）

 

2.4Hibernate的缓存机制

一、hibernate 一级缓存(属于应用事务级缓存)

（1）hibernate 支持两个级别的缓存，默认只支持一级缓存；

（2）每个 Session 内部自带一个一级缓存；

（3）某个 Session 被关闭时，其对应的一级缓存自动清除

一级缓存：

 

在数据库中存在一个对象，这个对象的地址存在与map中的key中，对应的值存在value中（快照区），当对象的值被修改后，事务执行了commit或者session执行了flush、close后，快照区就会和数据库中的内容进行对比，如果内容不一样则会发送update请求更新数据，让快照区中的值与数据库中的保存一致。首先更改的是数据库中的值，快照区对比不一样后才会去更新。

二 二级缓存（默认关闭）：
a) 应用及缓存
b) 分布式缓存
条件：数据不会被第三方修改、数据大小在可接受范围、数据更新频率低、同一数据被系统频繁使用、非关键数据
c) 第三方缓存的实现
  一级缓存：session级的缓存也叫事务级的缓存，只缓存实体，生命周期和session一致。不能对其进行管理。不用显式的调用。

二级缓存：sessionFactory缓存，也叫进程级的缓存，使用第3方插件实现的，也缓存实体，生命周期和sessionFactory一致，可以进行管理。

首先配置第3方插件，我们用的是EHCache，在hibernate.cfg.xml文件中加入

<property name="hibernate.cache.user_second_level_cache">true</property>

在映射中也要显示的调用，<cache usage="read-only"/>

二级缓存之查询缓存：对普通属性进行缓存。如果关联的表发生了修改，那么查询缓存的生命周期也结束了。

缓存是介于应用程序和物理数据源之间，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。

Hibernate的缓存包括Session的缓存和SessionFactory的缓存，其中SessionFactory的缓存又可以分为两类：内置缓存和外置缓存。

Session的缓存是内置的，不能被卸载，也被称为Hibernate的第一级缓存。SessionFactory的内置缓存和Session的缓存在实现方式上比较相似，前者是SessionFactory对象的一些集合属性包含的数据，后者是指Session的一些集合属性包含的数据。SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句，映射元数据是映射文件中数据的拷贝，而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来，SessionFactory的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义SQL语句，因此SessionFactory不需要进行内置缓存与映射文件的同步。

SessionFactory的外置缓存是一个可配置的插件。在默认情况下，SessionFactory不会启用这个插件。外置缓存的数据是数据库数据的拷贝，外置缓存的介质可以是内存或者硬盘。SessionFactory的外置缓存也被称为Hibernate的第二级缓存。

 

 

 

二级缓存实际上存的是散装数据（对象的属性），实际上是sessionFactory的缓存，二级缓中有两个区域class区域和collection区域，class区域是用于存数据的，collection区域不存数据；

当session关闭后，一级缓存消失，但是二级缓存还是存在

二级缓存查询数据，条件必须记录的id （任何以非id查询，无法使用二级缓存 ）

Hibernate的Session就是一种缓存，我们通常将之称为Hibernate的一级缓存，当想

使用session从数据库中查询出一个对象时，Session也是先从自己内部查看是否存在这个

对象，存在则直接返回，不存在才去访问数据库，并将查询的结果保存在自己内部。由于

Session代表一次会话过程，一个Session与一个数据库连接相关连，所以Session最好不

要长时间保持打开，通常仅用于一个事务当中，在事务结束时就应关闭。并且Session是

线程不安全的，被多个线程共享时容易出现问题。通常只有那种全局意义上的缓存才是真正

的缓存应用，才有较大的缓存价值，因此，Hibernate的Session这一级缓存的缓存作用并

不明显，应用价值不大。Hibernate的二级缓存就是要为Hibernate配置一种全局缓存，让

多个线程和多个事务都可以共享这个缓存。我们希望的是一个人使用过，其他人也可以使用，

session没有这种效果。二级缓存是独立于Hibernate的软件部件，属于第三方的产品，多个厂商和组织都提供有缓存产品，例如，EHCache和OSCache等等。

 

2.5Hibernate的查询方式

HQL查询，对象化查询Criteria方法，动态查询DetachedCriteria，例子查询，sql查询，命名查询。

HQL查询

HQL是hibernate自己的一套查询语言，于SQL语法不同，具有跨数据库的优点。示例代码：

static void query(String name){
  Session s=null;

  try{
   s=HibernateUtil.getSession();  

//from后面是对象，不是表名   

String hql="from Admin as admin where admin.aname=:name";

//使用命名参数，推荐使用，易读。 

Query query=s.createQuery(hql);
   query.setString("name", name);
   
   List<Admin> list=query.list(); 

  for(Admin admin:list){
    System.out.println(admin.getAname());
   }
  }finally{  

 if(s!=null)
   s.close();
  }
 }

 

适用情况：常用方法，比较传统，类似jdbc。缺点：新的查询语言，适用面有限，仅适用于Hibernate框架。

对象化查询Criteria方法：

 

static void cri(String name,String password){
  Session s=null; 

 try{
   s=HibernateUtil.getSession();
   
   Criteria c=s.createCriteria(Admin.class);
   c.add(Restrictions.eq("aname",name));//eq是等于，gt是大于，lt是小于,or是或  

 c.add(Restrictions.eq("apassword", password));
   
   List<Admin> list=c.list();   for(Admin admin:list){
    System.out.println(admin.getAname());
   }
  }finally{   if(s!=null)
   s.close();
  }
 }

 

适用情况：面向对象操作，革新了以前的数据库操作方式，易读。缺点：适用面较HQL有限。

动态分离查询DetachedCriteria

 

static List dc(DetachedCriteria dc) {

  Session s = HibernateUtil.getSession();
  Criteria c = dc.getExecutableCriteria(s);
  List rs = c.list();
  s.close();  return rs;
 }

 

 

DetachedCriteria dc = DetachedCriteria.forClass(User.class);  int id = 1; 

 if (id != 0)
   dc.add(Restrictions.eq("id", id));
  Date age = new Date();  

  if (age != null)
   dc.add(Restrictions.le("birthday", age));
  List users = dc(dc);
  System.out.println("离线查询返回结果：" + users);

 

适用情况：面向对象操作，分离业务与底层，不需要字段属性摄入到Dao实现层。  缺点：适用面较HQL有限。

例子查询

static List example(User user) {
  Session s = HibernateUtil.getSession();
  List<User> users = s.createCriteria(User.class).add(
    Example.create(user)).list();  // List<User>  // users2=s.createCriteria(User.class).add((Example.create(user)).ignoreCase())  // .createCriteria("child").add((Example.create(user))).list();  return users;
 }

 

适用情况：面向对象操作。   缺点：适用面较HQL有限，不推荐。

sql查询

static List sql() {

  Session s = HibernateUtil.getSession();
  Query q = s.createSQLQuery("select * from user").addEntity(User.class);
  List<User> rs = q.list();
  s.close();  return rs;
 }

 适用情况：不熟悉HQL的朋友，又不打算转数据库平台的朋友，万能方法   缺点：破坏跨平台，不易维护，不面向对象。

命名查询

 

static List namedQuery(int id) {
  Session s = HibernateUtil.getSession();
  Query q = s.getNamedQuery("getUserById");
  q.setInteger("id", id);  

  return q.list();
 }

 

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"><hibernate-mapping>    <class name="com.sy.vo.User" table="user" catalog="news">
    
    </class>    <!-- 命名查询：定义查询条件 -->    <query name="getUserById">     <![CDATA[from User where id=:id]]>    </query>    <!-- 命名查询中使用sql，不推荐使用，影响跨数据库
    <sql-query name="getUserById2">
     <![CDATA[select * from User where ]]>
    </sql-query> --></hibernate-mapping>

 

适用情况：万能方法，有点像ibatis轻量级框架的操作，方便维护。  缺点：不面向对象。基于hql和sql，有一定缺陷。

 1.Hibernate有哪几种查询数据的方式

      (1)导航对象图查询 （通过一个查询一个对象导航到另一个对象）

Order o = session.get(Order.class,1);//select * from itcast_order where id = ? Customer c = o.getCustomer();//select * from itcast_customer where id = ?

 

      (2)OID查询（通过id查询）get/load()方法

      (3)HQL（通过hql语句查询）

      (4)QBC（通过条件查询criteria）

Criteria criteria = session.createCriteria(Customer.class); //设置查询条件 criteria.add(Restrictions.eq("name", "abc")); criteria.add(Restrictions.eq("id", 5));

 

      (5)本地SQL

 

2.6  get与load的区别

load加载方法：

Users user = (Users)session.load(Users.class, userId);    

get加载方法：

Users user = (Users)session.get(Users.class, userId);  

 

两加载方法区别：

区别1：如果数据库中，没有userId的对象。如果通过get方法加载，则返回的是一个null；如果通过load加载，则返回一个代理对象，如果后面代码如果调用user对象的某个属性（比如user.getPassword()）会抛出异常：org.hibernate.ObjectNotFoundException；

区别2：load支持延迟加载，get不支持延迟加载。

Users user = (Users)session.load(Users.class, userId);  

这句代码不会去执行数据库查询，只有用到user时才会去执行数据库查询。

而：

Java代码

Users user = (Users)session.get(Users.class, userId);  

则立即去执行数据库查询。 所以Users user = (Users)session.load(Users.class, userId);不会执行任何sql。

注意：

Java代码

Users user = (Users)session.load(Users.class, userId);    
System.out.println(user.getId());  

上面这2句代码，不会去执行数据库操作。因为load后会在hibernate的一级缓存里存放一个map对象，该map的key就是userId的值，但是当你getId()时，它会去一级缓存里拿map的key值，而不去执行数据库查询。所以不会报任何错。不会执行任何数据库操作。

 

2.7 Hibernate优化

1.使用双向一对多关联，不使用单向一对多
2.灵活使用单向一对多关联
3.不用一对一，用多对一取代
4.配置对象缓存，不使用集合缓存
5.一对多集合使用Bag,多对多集合使用Set
6. 继承类使用显式多态
7. 表字段要少，表关联不要怕多，有二级缓存撑腰

 

初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。

 

大体上，对于HIBERNATE性能调优的主要考虑点如下:

　　Ø 数据库设计调整

　　Ø HQL优化

　　Ø API的正确使用(如根据不同的业务类型选用不同的集合及查询API)

　　Ø 主配置参数(日志，查询缓存，fetch_size, batch_size等)

　　Ø 映射文件优化(ID生成策略，二级缓存，延迟加载，关联优化)

　　Ø 一级缓存的管理

　　Ø 针对二级缓存，还有许多特有的策略

　　Ø 事务控制策略。

 

1、 数据库设计

　　a) 降低关联的复杂性 

　　b) 尽量不使用联合主键

　　c) ID的生成机制，不同的数据库所提供的机制并不完全一样

　　d) 适当的冗余数据，不过分追求高范式

2、 HQL优化

　　HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。

在性能瓶颈的地方使用硬编码的 JDBC。 

3、 主配置

　　a) 查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是，查询缓存在一个交易系统(数据变更频繁，查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用场。

　　b) fetch_size，同JDBC的相关参数作用类似，参数并不是越大越好，而应根据业务特征去设置

　　c) batch_size同上。

　　d) 生产系统中，切记要关掉SQL语句打印。

4、 缓存

　　a) 数据库级缓存:这级缓存是最高效和安全的，但不同的数据库可管理的层次并不一样，比如，在ORACLE中，可以在建表时指定将整个表置于缓存当中。

　　b) SESSION缓存:在一个HIBERNATE SESSION有效，这级缓存的可干预性不强，大多于HIBERNATE自动管理，但它提供清除缓存的方法，这在大批量增加/更新操作是有效的。比如，同时增加十万条记录，按常规方式进行，很可能会发现OutofMemeroy的异常，这时可能需要手动清除这一级缓存:Session.evict以及Session.clear

　　c) 应用缓存:在一个SESSIONFACTORY中有效，因此也是优化的重中之重，因此，各类策略也考虑的较多，在将数据放入这一级缓存之前，需要考虑一些前提条件:

　　i. 数据不会被第三方修改(比如，是否有另一个应用也在修改这些数据?)

　　ii. 数据不会太大

　　iii. 数据不会频繁更新(否则使用CACHE可能适得其反)

　　iv. 数据会被频繁查询

　　v. 数据不是关键数据(如涉及钱，安全等方面的问题)。

　　缓存有几种形式，可以在映射文件中配置:read-only(只读，适用于很少变更的静态数据/历史数据)，nonstrict-read-write，read-write(比较普遍的形式，效率一般)，transactional(JTA中，且支持的缓存产品较少)

　　d) 分布式缓存:同c)的配置一样，只是缓存产品的选用不同，在目前的HIBERNATE中可供选择的不多，oscache, jboss cache，目前的大多数项目，对它们的用于集群的使用(特别是关键交易系统)都持保守态度。在集群环境中，只利用数据库级的缓存是最安全的。

5、 延迟加载

　　a) 实体延迟加载:通过使用动态代理实现

　　b) 集合延迟加载:通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持

　　c) 属性延迟加载:

6、 方法选用

　　a) 完成同样一件事，HIBERNATE提供了可供选择的一些方式，但具体使用什么方式，可能用性能/代码都会有影响。显示，一次返回十万条记录(List/Set/Bag/Map等)进行处理，很可能导致内存不够的问题，而如果用基于游标(ScrollableResults)或Iterator的结果集，则不存在这样的问题。

　　b) Session的load/get方法，前者会使用二级缓存，而后者则不使用。

　　c) Query和list/iterator，如果去仔细研究一下它们，你可能会发现很多有意思的情况，二者主要区别(如果使用了Spring，在HibernateTemplate中对应find,iterator方法):

　　i. list只能利用查询缓存(但在交易系统中查询缓存作用不大)，无法利用二级缓存中的单个实体，但list查出的对象会写入二级缓存，但它一般只生成较少的执行SQL语句，很多情况就是一条(无关联)。

　　ii. iterator则可以利用二级缓存，对于一条查询语句，它会先从数据库中找出所有符合条件的记录的ID，再通过ID去缓存找，对于缓存中没有的记录，再构造语句从数据库中查出，因此很容易知道，如果缓存中没有任何符合条件的记录，使用iterator会产生N+1条SQL语句(N为符合条件的记录数)

　　iii. 通过iterator，配合缓存管理API，在海量数据查询中可以很好的解决内存问题，如:

　　while(it.hasNext()){

　　YouObject object = (YouObject)it.next();

　　session.evict(youObject);

　　sessionFactory.evice(YouObject.class, youObject.getId());

　　}

　　如果用list方法，很可能就出OutofMemory错误了。

　　iv. 通过上面的说明，我想你应该知道如何去使用这两个方法了。

7、 集合的选用

　　在HIBERNATE 3.6文档的“21.5理解集合性能”中有详细的说明。

² ists，maps 和 sets 用于更新效率最高

² Bag 和 list 是反向集合类中效率最高的

² 一次性删除（One shot delete）

 

8、 事务控制

　　事务方面对性能有影响的主要包括:事务方式的选用，事务隔离级别以及锁的选用

　　a) 事务方式选用:如果不涉及多个事务管理器事务的话，不需要使用JTA，只有JDBC的事务控制就可以。

　　b) 事务隔离级别:参见标准的SQL事务隔离级别

　　c) 锁的选用:悲观锁(一般由具体的事务管理器实现)，对于长事务效率低，但安全。乐观锁(一般在应用级别实现)，如在HIBERNATE中可以定义VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。

9、 批量操作

　　即使是使用JDBC，在进行大批数据更新时，BATCH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。

　　举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二级缓存，这样效率肯定高不了，在后续的版本中增加了bulk delete/update，但这也无法解决缓存的维护问题。也就是说，由于有了二级缓存的维护问题，HIBERNATE的批量操作效率并不尽如人意!

　　从前面许多要点可以看出，很多时候我们是在效率与安全/准 确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解，一般的，优化方案应在架构设计期就基本确定，否则 可能导致没必要的返工，致使项目延期，而作为架构师和项目经理，还要面对开发人员可能的抱怨，必竟，我们对用户需求更改的控制力不大，但技术/架构风险是应该在初期意识到并制定好相关的对策。

还有一点要注意，应用层的缓存只是锦上添花，永远不要把它当救命稻草，应用的根基(数据库设计，算法，高效的操作语句，恰当API的选择等)才是最重要的。

 

2.8 Hibernate与jdbc的联系与优缺点

二者的联系：

JDBC是java应用程序连接数据库，进行数据存取的一种机制，是一组用java语言编写的类和接口的API，它和数据库之间由各个厂商提供的数据库驱动进行关联。

hibernate是一个开源的轻量级的ORM框架，它在底层对jdbc进行了封装。

 

优点：

hibernate的最主要的几个优点是：

一、hibernate可以让开发人员以面相对象的思想来操作数据库。jdbc只能通过SQL语句将元数据传送给数据库，进行数据操作。而hibernate可以在底层对元数据和对象进行转化，使得开发者只用面向对象的方式来存取数据即可。

 

二、hibernate使用xml或JPA的配置以及数据库方言等等的机制，使得hibernate具有更好的移植性，对于不同的数据库，开发者只需要使用相同的数据操作即可，无需关心数据库之间的差异。而直接使用JDBC就不得不考虑数据库差异的问题。

 

三、hibernate提供了大量的封装（这也是它最大的缺点），很多数据操作以及关联关系等都被封装的很好，开发者不需写大量的sql语句，这就极大的提高了开发者的开发效率。

 

四、hibernate提供了缓存机制（session缓存，二级缓存，查询缓存），对于那些改动不大且经常使用的数据，可以将它们放到缓存中，不必在每次使用时都去查询数据库，缓存机制对提升性能大有裨益。

 

缺点：

一、有时优点也即缺点，对hibernate而言，它对JDBC封装过于厉害，所以就失去了对SQL的控制（当然hibernate也可以使用native sql既使用createSQLQuery等方法来调用与数据库相关的sql，但这样一来也就影响了hibernate的可移植性），使得hibernate的在很多地方不够灵活，难于优化，尤其对于一些复杂的关联查询时，hibernate提供的功能远不及直接使用JDBC方便性能更高。

 

二、hibernate没有提供专门的批处理机制，如果要批量更新或插入数据时，还需要显示的flush，clear之类的操作，性能不如JDBC。

 

三、相对于JDBC，hibernate更消耗内存，因为它每次的数据库操作都要做数据和对象的转换/封装，查询出一条数据就要创建一个或多个对象，这样也太消耗内存了。

 

四、hibernate提供了很多好处，但这些好处本身就是陷阱（如proxy陷阱等），开发者如果不注意就会调入陷阱而不知，这样就可能会出现一些无法排查的异常情况，比如程序表面上看着毫无错误，可就是达不到预期的效果，而且并无异常抛出，断点排查也不一定能找到症结所在，这将是非常令人抓狂的一件事！！！！！

 

2.9Hibernate和mybatis的区别

1. hibernate是全自动，而mybatis是半自动。

hibernate完全可以通过对象关系模型实现对数据库的操作，拥有完整的JavaBean对象与数据库的映射结构来自动生成sql。而mybatis仅有基本的字段映射，对象数据以及对象实际关系仍然需要通过手写sql来实现和管理。

2. hibernate数据库移植性远大于mybatis。

hibernate通过它强大的映射结构和hql语言，大大降低了对象与数据库（oracle、mysql等）的耦合性，而mybatis由于需要手写sql，因此与数据库的耦合性直接取决于程序员写sql的方法，如果sql不具通用性而用了很多某数据库特性的sql语句的话，移植性也会随之降低很多，成本很高。

3. hibernate拥有完整的日志系统，mybatis则欠缺一些。

hibernate日志系统非常健全，涉及广泛，包括：sql记录、关系异常、优化警告、缓存提示、脏数据警告等；而mybatis则除了基本记录功能外，功能薄弱很多。

4. mybatis相比hibernate需要关心很多细节

hibernate配置要比mybatis复杂的多，学习成本也比mybatis高。但也正因为mybatis使用简单，才导致它要比hibernate关心很多技术细节。mybatis由于不用考虑很多细节，开发模式上与传统jdbc区别很小，因此很容易上手并开发项目，但忽略细节会导致项目前期bug较多，因而开发出相对稳定的软件很慢，而开发出软件却很快。hibernate则正好与之相反。但是如果使用hibernate很熟练的话，实际上开发效率丝毫不差于甚至超越mybatis。

5. sql直接优化上，mybatis要比hibernate方便很多

由于mybatis的sql都是写在xml里，因此优化sql比hibernate方便很多。而hibernate的sql很多都是自动生成的，无法直接维护sql；虽有hql，但功能还是不及sql强大，见到报表等变态需求时，hql也歇菜，也就是说hql是有局限的；hibernate虽然也支持原生sql，但开发模式上却与orm不同，需要转换思维，因此使用上不是非常方便。总之写sql的灵活度上hibernate不及mybatis。

 

总结：

mybatis：小巧、方便、高效、简单、直接、半自动

hibernate：强大、方便、高效、复杂、绕弯子、全自动

 

mybatis：

1. 入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。

2. 可以进行更为细致的SQL优化，可以减少查询字段。

3. 缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。

4. 二级缓存机制不佳。

hibernate：

1. 功能强大，数据库无关性好，O/R映射能力强，如果你对Hibernate相当精通，而且对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发速度很快，非常爽。

2. 有更好的二级缓存机制，可以使用第三方缓存。

3. 缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行。

举个形象的比喻：

mybatis：机械工具，使用方便，拿来就用，但工作还是要自己来作，不过工具是活的，怎么使由我决定。

hibernate：智能机器人，但研发它（学习、熟练度）的成本很高，工作都可以摆脱他了，但仅限于它能做的事。



2.10  Hibernate 的 sessionfactory 和 session 的区别及其处理 session 线程不安全问题

sessionfactory 是一个数据源对应着一个 sessionfactory,也就说他是属于二级缓存,如果是

集群环境,他可以动态的配置使用这个数据源或者

不使用这个数据源,session 是等于一次回话,也就是说是一级缓存,并且是由 sessionfactory

创建的,再有 sessionfactory 是线程安全的,相反的

session 不安全的;

解决 session 不安全的问题,就是大家通常用的常规写法,一次会话后关闭 session,避免

session 重用;

 

2.11 Hibernate 如何实现动态查询及其DetachedCriteria 与 Criteria 的区别

条件查询,编程的方式代替 HQL 语句,DetachedCriteria 单词很简明了,Detached 是分离,

分离,分离什么,当然是业务层的应用,原本的Criteria 是与 session 绑定的,现在用DetachedCriteria这个来分离。

本质:criteria需要Session绑定，DetachedCriteria不需要Session，通过对象即可查询，通过forClass（字节码对象）

2.12Hibernate持久化的3种状态

1)瞬时(临时)：没有与session关联，没有持久化标志OID（OID 为null）

2)持久: 与session关联，有持久化标志OID

3)托管（离线）: 没有与session关联，有持久化标志OID

瞬时态 transient  尚未与Hibernate Session关联对象，被认为处于瞬时状态，失去引用将被JVM回收

无持久化标识OID，未与Session关联

持久态 persistent 数据库中有数据与之对应并与当前session有关联，并且相关联的session没有关闭数据库并且事务未提交 

存在持久化标识OID，与Session关联

脱管态 detached 数据库中有数据与之对应，但当前没有session与之关联，脱管状态改变hibernate不能检测到

存在持久化标识OID，未与Session关联

 

对象的状态是可以相互转化的

如何直接获得一个瞬时对象：User user = new User();

瞬时---》持久对象  session.save(user);session.saveOrUpdate(user);

瞬时---》托管对象  user.setId(1); 

如何直接获得一个持久对象:

session.get(User.class,1);session.load(User.class,1);query.list();---所有的查询方法获得的对象都是持久对象

持久---》瞬时对象  session.delete(user); 

持久---》托管对象  session.close();session.clear();session.evict(user);---清理缓存

 

如何直接获得一个托管对象：没有办法直接获得托管，必须由其他对象转化

托管---》瞬时对象  user.setId(null);

托管---》持久对象  session.update(user);session.saveOrUpdate(user);

2.13Hibernate中主键生成策略的几种方式

1、自动增长identity

适用于MySQL、DB2、MS SQL Server，采用数据库生成的主键，用于为long、short、int类型生成唯一标识
使用SQL Server 和 MySQL 的自增字段，这个方法不能放到 Oracle 中，Oracle 不支持自增字段，要设定sequence（MySQL 和 SQL Server 中很常用）
数据库中的语法如下：
MySQL：create table t_user(id int auto_increment primary key, name varchar(20));
SQL Server：create table t_user(id int identity(1,1) primary key, name varchar(20));

<id name="id" column="id" type="long">
    <generator class="identity" />
</id>

2、sequence

DB2、Oracle均支持的序列，用于为long、short或int生成唯一标识
数据库中的语法如下：
Oracle：create sequence seq_name increment by 1 start with 1;
需要主键值时可以调用seq_name.nextval或者seq_name.curval得到，数据库会帮助我们维护这个sequence序列，保证每次取到的值唯一，如：
insert into tbl_name(id, name) values(seq_name.nextval, ‘Jimliu’);

<id name="id" column="id" type="long">
    <generator class="sequence">
       <param name="sequence">seq_name</param>
   </generator>
</id>

如果我们没有指定sequence参数，则Hibernate会访问一个默认的sequence，是hibernate_sequence，我们也需要在数据库中建立这个sequence
此外，sequence还可以有另外一个参数是paramters，可以查看Hibernate的API了解它的用法，见org.hibernate.id.SequenceGenerator
调用数据库的sequence来生成主键，要设定序列名，不然hibernate无法找到：
<param name="sequence">NAME_SEQ</param>（Oracle中很常用）

3、hilo

使用一个高/低位算法生成的long、short或int类型的标识符，给定一个表和字段作为高位值的来源，默认的表是hibernate_unique_key，默认的字段是next_hi。它将id的产生源分成两部分，DB+内存，然后按照算法结合在一起产生id值，可以在很少的连接次数内产生多条记录，提高效率

MySQL：create table hi_value(next_hi integer not null);

insert into hi_value(next_hi) values(1);

<id name="id" column="id">
    <generator class="hilo">
       <param name="table">hi_value</param>
       <param name="column">next_hi</param>
       <param name="max_lo">100</param>
   </generator>
</id>

在hibernate持久化的时候，由hibernate负责生成低位值。hilo标识符生成器在生成标识符时需要从hi_value表中取出next_hi的当前值，然后修改该值，这个操作是在单独的事务中完成的。最大的低值在属性max_lo中配置，但在Hibernate内存中生成的低位值超过此值时，就有需要到数据库的hi_value表中再次读取高位值了
使用hilo生成策略，要在数据库中建立一张额外的表，默认表名为hibernate_unique_key,默认字段为integer类型，名称是next_hi（比较少用）
我们也可以自己设置自定义的表名和字段名
<id name="id" type="integer">
   <column name="id"/>
   <generator class="hilo">
      <param name="my_unique_key"/>
      <param column="next_hi"/>
   </generator>
</id>

4、native

会根据底层数据库的能力，从identity、sequence、hilo中选择一个，灵活性更强，但此时，如果选择sequence或者hilo，则所有的表的主键都会从Hibernate默认的sequence或者hilo表中取。并且，有的数据库对于默认情况主键生成测试的支持，效率并不是很高
     对于 oracle 采用 Sequence 方式，对于MySQL 和 SQL Server 采用identity（自增主键生成机制），native就是将主键的生成工作交由数据库完成，hibernate不管（很常用）

<id name="id" column="id">
    <generator class="native" />
</id>

5、seqhilo

sequence和hilo的结合，hilo的高位由sequence产生，所以也需要底层数据库的支持
通过hilo算法实现，但是主键历史保存在Sequence中，适用于支持 Sequence 的数据库，如 Oracle（比较少用）

<id name="id" column="id">
   <generator class="seqhilo">
      <param name="sequence">seq_name</param>
      <param name="max_lo">100</param>
   </generator>
</id>

6、increment

这个是由Hibernate在内存中生成主键，每次增量为1，不依赖于底层的数据库，因此所有的数据库都可以使用，但问题也随之而来，由于是Hibernate生成的，所以只

能有一个Hibernate应用进程访问数据库，否则就会产生主键冲突，不能在集群情况下使用
插入数据的时候hibernate会给主键添加一个自增的主键，但是一个hibernate实例就维护一个计数器，所以在多个实例运行的时候不能使用这个方法
<id name="id" column="id">
    <generator class="increment" />
</id>

7、uuid.hex

使用一个128-bit的UUID算法生成字符串类型的标识符，UUID被编码成一个32位16进制数字的字符串。UUID包含：IP地址、JVM启动时间、系统时间（精确到1/4秒）和一个计数器值（JVM中唯一）
hibernate会算出一个128位的唯一值插入

<id name="id" column="id">
    <generator class="uuid.hex" />
</id>
uuid.string
       hibernate会算出一个16位的值插入

8、assigned

由应用程序负责生成主键标识符，往往使用在数据库中没有代理主键，使用的主键与业务相关的情况，如：

<id name="id" column="id" type="string">
    <generator class="assigned" />
</id>
这种主键的生成方式不建议使用，在数据库表设计时就应该使用代理主键（surrogate key），不应使用自然主键（natural key具有业务含义），在没有指定<generator>标签时，默认就是assigned主键的生成方式
在插入数据的时候主键由用户自己添加，hibernate也不管

9、foreign
使用外部表的字段作为主键

10、select
使用触发器生成主键（主要用于早期的数据库主键生成机制，少用）

ps:

代理主键是指与业务无关且能唯一标识数据库中记录,一般是数据库自动生成的,比如mysql可以使用auto_increment,Sql2000可以使用identity生成方式,oracle可以使用sequence生成方式 自然主键指业务相关,由用户指定,且能唯一标识数据库中的任意一条记录

 

简介版：

increment：代理主键，适合于所有数据库，由hibernate维护主键自增，和底层数据库无关，但是不适合于2个或以上hibernate进程。

identity：代理主键，适合于Mysql或ms sql server等支持自增的dbms，主键值不由hibernate维护。

sequence：代理主键，适合于oracle等支持序列的dbms，主键值不由hibernate维护，由序列产生。

native：代理主键，根据底层数据库的具体特性选择适合的主键生成策略，如果是mysql或sqlserver，选择identity，如果是oracle，选择sequence。

hilo：代理主键，hibernate把特定表的字段作为hign值，生成主键值

uuid.hex：代理主键，hibernate采用uuid 128位算法生成基于字符串的主键值

assign：适合于应用程序维护的自然主键。

2.14 oracle中的两种自增策略

创建序列和创建存储过程

1，创建序列

CREATE SEQUENCE my_seq 　　　　 　　　　----以my_seq为名创建序列
START WITH 1 　　　　　　 　　　　　　 　　 ----从1开始递增，可以是其他数字
INCREMENT BY 1　　　　 　　　　　　　　      ----步进为1
MAXVALUE 99999999999 [NOMAXVALUE]----递增的最大值，NOMAXVALUE没有最大值
NOCYCLE ----CYCLE在有最大值时，达到最大值99999999999后循环从1开始再次递增，NOCYCLE不循环
CACHE 20----缓存，默认为20
NOORDER; 　　　　　　　　　　　　　　　　　 ----还没明白这个是干什么的，不过暂时可有可无 

2，创建存储过程

CREATE TRIGGER my_trigger BEFORE INSERT ON table_name FOR EACH ROW
BEGIN SELECT my_seq.NEXTVAL INTO :NEW.column_name FROM DUAL;
END; 

这样就完成了，在插入的时候就column_name字段就可以自动增长了。

 

3.spring

3.1 Spring中的AOP与IOC、DI

AOP面向切面编程（AOP）完善spring的依赖注入（DI），面向切面编程在spring中主要表现为两个方面

1.面向切面编程提供声明式事务管理 

2.spring支持用户自定义的切面 

 

面向切面编程（aop）是对面向对象编程（oop）的补充， 

面向对象编程将程序分解成各个层次的对象，面向切面编程将程序运行过程分解成各个切面。 

AOP从程序运行角度考虑程序的结构，提取业务处理过程的切面，oop是静态的抽象，aop是动态的抽象，是对应用执行过程中的步骤进行抽象，，从而获得步骤之间的逻辑划分。 

 

IOC是Inversion of Control的缩写，控制反转，简单来说就是把复杂系统分解成相互合作的对象，借助于“第三方”实现具有依赖关系的对象之间的解耦。 这里的第三方 就是指Ioc容器（Spring 框架），所有对象的创建权，都交由Spring管理。

 

DI的出现，是对IoC的更近一步分析，既然IOC是控制反转，那么到底是“哪些方面的控制被反转了呢？经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。

 

依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。

 

3.2 Spring中BeanFactory和ApplicationContext的区别

ApplicationContext 为它增加了更强的功能，这些功能中的一些或许更加接近

J2EE 并且围绕企业级应用。一般来说，ApplicationContext 是  BeanFactory 的 完全超集，  任何 BeanFactory 功能和行为的描述也同样被认为适用于 ApplicationContext

相对于 BeanFactory 而言,ApplicationContext 提供了以下扩展功能.

 

1.BeanFactory采用的是延迟加载形式来注入bean的，即只有在使用到某个Bean时（调用getBean()）,才对该Bean进行加载实例化，这样，我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误。

ApplicationContext建立在BeanFactory之上，并增加了其他的功能。如：(a) 国际化支持 (b) 资源访问    (c) 事件传播 (d) 多实例加载

2. （更容易同Spring AOP 特性整合，消息资源处理（用于国际化），事件传递，以声明式方式创建ApplicationContext，可选的父上下文和应用层相关的上下文，以及其他方面的增强。）

3.3 spring中的事务提交

编程式：通过TransactionTemplate 实现 

声明式：基于AOP 切面编程实现 ，无需编码，灵活性更高（通过配置文件或者注解）

 

3.4 Spring的作用域

创建一个bean定义，其实质是用该bean定义对应的类来创建真正实例的“配方(recipe)”。把bean定义看成一个配方很有意义，它与class很类似，只根据一张“处方”就可以创建多个实例。

你不仅可以控制注入到对象中的各种依赖和配置值，还可以控制该对象的作用域。这样你可以灵活选择所建对象的作用域，而不必在Java Class级定义作用域。Spring Framework支持五种作用域（其中有三种只能用在基于web的Spring ApplicationContext）。

1、singleton:当一个bean的作用域为singleton, 那么Spring IoC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。

注意：Singleton作用域是Spring中的缺省作用域。要在XML中将bean定义成singleton，可以这样配置： 

<bean id="empServiceImpl" class="cn.csdn.service.EmpServiceImpl" scope="singleton">

2、prototype：一个bean定义对应多个对象实例。Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。根据经验，对有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。

3、request：在一次HTTP请求中，一个bean定义对应一个实例；即每次HTTP请求将会有各自的bean实例， 它们依据某个bean定义创建而成。该作用域仅在基于web的Spring ApplicationContext情形下有效。

考虑下面bean定义：

<bean id="loginAction" class=cn.csdn.LoginAction" scope="request"/>

针对每次HTTP请求，Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例， 且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态， 而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。 当处理请求结束，request作用域的bean实例将被销毁。

4、session：在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。

考虑下面bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例， 且该userPreferences bean仅在当前HTTP Session内有效。 与request作用域一样，你可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例， 将不会看到这些特定于某个HTTP Session的状态变化。 当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。

5、global session：在一个全局的HTTP Session中，一个bean定义对应一个实例。典型情况下，仅在使用portlet context的时候有效。该作用域仅在基于web的Spring ApplicationContext情形下有效。

考虑下面bean定义：

<bean id="userPreferences" class="com.foo.UserPreferences" scope="globalSession"/>

global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。

请注意：假如你在编写一个标准的基于Servlet的web应用，并且定义了一个或多个具有global session作用域的bean，系统会使用标准的HTTP Session作用域，并且不会引起任何错误。

3.5 Spring使用属性注入方式

两种依赖注入的类型分别是setter注入和构造方法注入。

setter注入： 一般情况下所有的java bean, 我们都会使用setter方法和getter方法去设置和获取属性的值。

构造方法注入：使用带参数的构造方法

 

3.6Spring配置文件applicationContext.xml 能不能改名

ContextLoaderListener是一个ServletContextListener, 它在你的web应用启动的时候初始化。缺省情况下， 它会在WEB-INF/applicationContext.xml文件找Spring的配置。 你可以通过定义一个<context-param>元素名字为”contextConfigLocation”来改变Spring配置文件的位置。

<context-param>

        <param-name>contextConfigLocation</param-name>

        <param-value>/WEB-INF/itcast.xml</param-value>

</context-param>

 

3.7 Spring的声明式事务的如何实现的？

使用内置 TransactionProxyFactoryBean 为目标对象创建AOP代理对象，通过指定TransactionManager 对目标对象的方法添加事务管理操作 

 

3.8 Spring AOP编程原理？项目中如何使用的？

将传统继承的代码复用，变为代码的横向抽取机制，通过 代理机制，向目标对象织入增强代码。

Spring AOP底层基于 Jdk动态代理和Cglib 动态代理 实现

 

项目中用到的Spring中的切面编程最多的地方：声明式事务管理。

   a、定义一个事务管理器

   b、配置事务特性(相当于声明通知。一般在业务层的类的一些方法上定义事务)

   c、配置哪些类的哪些方法需要配置事务(相当于切入点。一般是业务类的方法上)

 

3.9 Spring提供哪些事务传播行为 ？

PROPAGATION_REQUIRED–支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 

PROPAGATION_SUPPORTS–支持当前事务，如果当前没有事务，就以非事务方式执行。 

PROPAGATION_MANDATORY–支持当前事务，如果当前没有事务，就抛出异常。 

PROPAGATION_REQUIRES_NEW–新建事务，如果当前存在事务，把当前事务挂起。 

PROPAGATION_NOT_SUPPORTED–以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 

PROPAGATION_NEVER–以非事务方式执行，如果当前存在事务，则抛出异常。 

PROPAGATION_NESTED–如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。

 

事务传播行为，主要用于解决，两个事务方法互相调用的问题，例如A方法开启事务，调用B方法，B方法也进行事务管理，A方法和B方法的事务是怎样的关系问题。 

 

3.10如果不用Spring如何实现AOP和IOC功能

说到底，IOC就是反射，实例化指定类；AOP就是拦截，一系列的过滤器

IOC：工厂模式通过读取配置文件创建实例结合反射使用，在配置文件里面配置要实例化的对象的全路径 

AOP：意为面向切面的编程，可以为某一类对象进行监督和控制，也就是调用你这个对象的方法前或者方法后，去调用你指定的模块从而达到一个对模块扩充的功能，一般用来做权限控制和日志记录等等，不用AOP的话，Struts2的拦截器也可以实现，不用Struts2，也可以直接用过滤器

补充：

AOP（Aspect-Oriented Programming，面向切面的编程），它是可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。它是一种新的方法论，它是对传统OOP编程的一种补充。 

IoC，（Inverse of Control）控制反转，其包含两个内容：其一是控制，其二是反转。在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决，它是一种设计模式，通过Java反射技术实现。

 

Springmvc工作原理

 

Spring工作流程描述

      1. 用户向服务器发送请求，请求被Spring 前端控制Servlet DispatcherServlet捕获；

      2. DispatcherServlet对请求URL进行解析，得到请求资源标识符（URI）。然后根据该URI，调用HandlerMapping获得该Handler配置的所有相关的对象（包括Handler对象以及Handler对象对应的拦截器），最后以HandlerExecutionChain对象的形式返回；

      3. DispatcherServlet 根据获得的Handler，选择一个合适的HandlerAdapter。（附注：如果成功获得HandlerAdapter后，此时将开始执行拦截器的preHandler(...)方法）

      4.  提取Request中的模型数据，填充Handler入参，开始执行Handler（Controller)。 在填充Handler的入参过程中，根据你的配置，Spring将帮你做一些额外的工作：

      HttpMessageConveter： 将请求消息（如Json、xml等数据）转换成一个对象，将对象转换为指定的响应信息

      数据转换：对请求消息进行数据转换。如String转换成Integer、Double等

      数据格式化：对请求消息进行数据格式化。 如将字符串转换成格式化数字或格式化日期等

      数据验证： 验证数据的有效性（长度、格式等），验证结果存储到BindingResult或Error中

      5.  Handler执行完成后，向DispatcherServlet 返回一个ModelAndView对象；

      6.  根据返回的ModelAndView，选择一个适合的ViewResolver（必须是已经注册到Spring容器中的ViewResolver)返回给DispatcherServlet ；

      7. ViewResolver 结合Model和View，来渲染视图

      8. 将渲染结果返回给客户端。