1.get() 採用立即載入方式,而 load() 採用延遲載入;
2.get() 方法執行的時候,會立即向資料庫發出查詢語句,而 load() 方法返回的是一個代理(此代理中只有一個 OID 屬性),只有等真正使用該物件屬性的時候,才會發出 sql 語句並執行 3.如果資料庫中沒有對應的記錄 , get() 方法返回的是 null . 而 load() 方法出現異常 ObjectNotFoundException

      我在資料層中封裝了一個 load() 方法，根據使用者 Id 獲取使用者物件：

public UserModel getUserById(Long uuid) {
        return this.getHibernateTemplate().load(UserModel.class, uuid);
        //return this.getHibernateTemplate().get(UserModel.class, uuid);
    }
 

        當在業務層呼叫了這個方法後，獲得一個 userModel 物件，當展示使用者資訊時，就會報出 noSession 問題，

public String get(){
        //報出了 org.hibernate.LazyInitializationException: could not initialize proxy - no Session異常
        UserModel temp = userEbi.get(1L);
        System.out.println(temp.getName());
        System.out.println(temp.getAge());
        return "haha";
    }
 

報出的異常如下：

原因：

        這是因為資料層提供的 load() 方法具有延遲載入的特性，在呼叫 load方法時，Hibernate 不會立即執行 sql 語句，而是動態的生成一個 UserModel 的代理物件例項，這個代理物件只具有 OID，也就是 uuid 值【這個值來自於形參，而不是資料庫】，該物件的其他資訊都沒有。

這個動態代理物件所具有的特性有：

1. 代理類物件和真實的 UserModel 物件無異，但是隻具有 OID，其他屬性均為 null，所以會比較省記憶體，這也是延遲載入的好處
2. 當第一次訪問這個代理類物件時，呼叫器 getXxx 方法時不會出問題，Hibernate 才會初始化這個代理物件，並會自動去執行 sql 語句去查詢其資料庫中的資料，【也就是 Service 層中的同一個方法，一旦這個方法彈棧，即事務提交結束，session 被關閉，】。

       當需要這個只具有 OID 的代理物件傳遞到了業務層（如果在事務關閉session之前立馬進行二次查詢，就不會出問題），此時物件仍是一個延遲載入物件（只具有 OID），如果傳遞到了表現層（action內），此時該物件依然是延遲載入物件（但此時早在業務層，方法早已彈棧，事務就已經將 session 關閉了，一旦要進行二次查詢就會報異常, 因為 session物件已經被重新整理了，也就是連線斷開了，session 中儲存的資料早已丟失），值得一說的是在表現層使用二次查詢是比較正常的需求。

解決這個問題有三個途徑：

• 在全域性取消延遲載入資料
• 在區域性取消延遲載入資料
• 將 session 的範圍擴大，擴大到表現層【此時就是 action 內 】

第一種：在全域性取消延遲載入資料，【這裡的全域性指的是某個表，並不是整個資料庫】

<?xml version="1.0"?>  
    <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"  
                                       "http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd">  
    <hibernate-mapping package="com.msym.entity">  
    <!-- 取消對於 user_db 表的延遲載入屬性 -->  
     <class name="User" table="user_db" lazy="false" >  
      <id name="id">  
       <generator class="identity"/>  
      </id>  
      <property  name="password" />  
      <property  name="name" />
      <property  name="nickName" />    
      <property  name="age" />  
      <property  name="birthday" />  
     </class>  
    </hibernate-mapping>

優點：簡單方便；

缺點：對於這個表，取消了延遲載入，在很多情況下會導致記憶體佔用大的問題，取出了原本不需要的資料。

第二種：在區域性取消延遲載入，【在 Service 層和 dao 層都可以區域性取消延遲載入屬性】

public UserModel getUserById(Long uuid) {
        UserModel u =  this.getHibernateTemplate().load(UserModel.class, uuid);
        Hibernate.initialize(u);
        return u；

        //return this.getHibernateTemplate().get(UserModel.class, uuid);
    }

優點：相比第一種，更加具有針對性，更加的靈活；

缺點：程式碼量稍稍多了一點點【但是也不要緊】。

第三種：擴大 session 的範圍，

       也就是要做到當前 session 在 Service 層的方法彈棧後不隨事務的提交而關閉，直到一次請求與響應完成才關閉。這時用到的一個技術就是 openSessionInView，將 session 與當前請求對應的執行緒繫結在一起【此 session 並非瀏覽器會話級別的 session，而是資料庫連線的 session】，這需要在 web.xml 中配置一個過濾器，這時註解的事務的任務就是開啟事務，重新整理事務；關閉事物的功能交給了 OpenSessionInViewFilter 這個類了，因為這個過濾器配置在一個，請求物件 request 最先接觸到它，請求結束時的最後一個過濾器也是它（這就是過濾器鏈了，往返要都過濾一次）。程式碼在下面：（一定要將 OpenSessionInViewFilter 配置在所有過濾器的前面）

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
    http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

    <!-- applicationContext物件載入僅載入一次，伺服器啟動時載入，使用web中的監聽器機制 -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:applicationContext.xml</param-value>
    </context-param>
    
    <!-- OpenSessionInView解決noSession問題，一定要配置在核心過濾器的前面 -->
    <filter>
        <filter-name>openSessionInView</filter-name>
        <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>

        <init-param>
            <param-name>sessionFactoryBeanName</param-name>
            <param-value>sessionFactory</param-value>
        </init-param>

        <init-param>
            <param-name>singleSession</param-name>
            <param-value>true</param-value>           
        </init-param>

        <init-param>
            <param-name>flushMode</param-name>
            <param-value>AUTO</param-value>        
        </init-param>

    </filter>
    <filter-mapping>
        <filter-name>openSessionInView</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>


    <!-- struts核心過濾器 -->
    <filter>
        <filter-name>struts2</filter-name>
        <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>struts2</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

</web-app>

OpenSessionInViewFilter 配置了三個引數：singleSession，sessionFactoryBeanName ，flushMode，

這幾個屬性都有其預設值，分別是，true，SessionFactory，MANUAL【手動提交事務】。

其中只是將 flushMode的預設屬性修改了，是為了防止出現 FlushModel 相關的異常。

      因為上面使用的是【org.springframework.orm.hibernate3.support.OpenSessionInViewFilter】這些屬性在其中都能找到，

但是如果使用的是 hibernate4.support 的話，這些屬性的位置就發生了變化，
其中：

       (1) . sessionFactoryBeanName 還是在 OpenSessionInViewFilter裡面，預設值也是 sessionFactory 如下圖：

       (2) . singleSession 預設值也是 true

       (3) . flushMode 屬性來自於 Session 這個介面，預設值也是MANUAL【手動提交事務】。

       它表示事務的提交方式，有如下幾種：

優點：配置簡單，

缺點：攔截了所有請求，效率不高，如果物件導航層級較多，會導致頁面的載入速度變慢，延長了 Session的生命週期，加重了伺服器的負擔。

總結：

        到最後推薦使用第二種，也就是區域性取消延遲載入特性，靈活性更好。