內(nèi)存溢出異常解決方案總結(jié)

內(nèi)存溢出特別解決方案總結(jié)內(nèi)存溢出特別解決方案總結(jié)—調(diào)整虛擬機(jī)參數(shù)二馬上釋放無用的對(duì)象三利用序列化和反序列化技術(shù)java中的堆和棧java把內(nèi)存分兩種：一種是棧內(nèi)存，另一種是堆內(nèi)存1。在函數(shù)中定義的根本類型變量和對(duì)象的引用變量都在函數(shù)的棧內(nèi)存中安排；2。堆內(nèi)存用來存放由new創(chuàng)立的對(duì)象和數(shù)組java內(nèi)存溢出數(shù)據(jù)量過于浩大死循環(huán)靜態(tài)變量和靜態(tài)方法過多無法確定是否被引用的對(duì)象，a虛擬機(jī)不回收內(nèi)存〔內(nèi)存泄漏，循環(huán)產(chǎn)生過多重復(fù)的對(duì)象實(shí)體程來處理為止，從而可以防止資源缺乏Context，request，session，application生命周期request是封裝client端〔也就是用戶通過browser〕提交的懇求數(shù)據(jù)和屬性的對(duì)象。responsewebserver我們常常會(huì)將Context、request、sessionapplication通過setAttribute和getAttribute來設(shè)定或讀取屬性。但它們之間是有別的，它們最大的區(qū)分在于使用范圍。Context對(duì)象的范圍只適用于當(dāng)前頁面范圍，即超過這個(gè)頁面就不能夠使用了。所以使Contextrequest對(duì)象的范圍是指在一JSP網(wǎng)頁發(fā)出懇求到另一個(gè)JSP效。session的作用范圍為一段用戶持續(xù)和效勞器所連接的時(shí)間，但與效勞器斷線后，這個(gè)屬性就無效。比方斷網(wǎng)或者關(guān)閉掃瞄器。application的范圍在效勞器一開頭執(zhí)行效勞，到效勞器關(guān)閉為止。它的范圍最大，生存周期最長(zhǎng)。session主要功能：驗(yàn)證用戶是否登錄。在幾個(gè)頁面上都能取得。request：只有<jsp:forward=““>跳轉(zhuǎn)頁面才能取得。application:只要設(shè)置一次，全部的網(wǎng)頁窗口都可以取得數(shù)據(jù)。applicationsessionrequest->都需要跨多個(gè)頁面設(shè)置過多application或每一個(gè)session能使用request就不要使用session能使用session的就不要使用applicationapplication應(yīng)用：在線人員統(tǒng)計(jì)、在線人員名單列表Context:默認(rèn)狀況下一個(gè)頁面的保存范圍實(shí)際上四種屬性范圍都是通過ContextContext.setAttribute(“name“,“mldn“,Context.REQUEST_SCOPE);更改紅字的名字得到。在 另 外 一 頁 用 request 去 接 收 Stringname=(String)request.getAttribute(“name“);<%=name%>;假設(shè)要釋放application資源要重啟動(dòng)效勞器四種屬性范圍都是依靠Contextsession和request范圍最多。JMS假設(shè)用過JMS的話，會(huì)覺察它類似寫JDBC或JCA代碼。它有創(chuàng)立或檢索JMS資源的樣板代碼，每當(dāng)你需要編寫一個(gè)類來發(fā)送或承受消息時(shí)，都得重復(fù)編寫那個(gè)樣本代碼。下面列出了傳統(tǒng)JMS實(shí)現(xiàn)涉及的步驟：JNDIcontext；2JNDI上下文獲得隊(duì)列連接工廠；4Session對(duì)象；5、創(chuàng)立一個(gè)發(fā)送或承受對(duì)象；65部創(chuàng)立的發(fā)送或承受對(duì)象發(fā)送或承受消息；7JMS資源。Hibernate緩存機(jī)制以及一級(jí)緩存和二級(jí)緩存的作用Hibernate的緩存機(jī)制概念：java對(duì)象的屬性〔通常是一些集合類型的屬性大就稱為重量級(jí)的對(duì)象。假設(shè)對(duì)象的內(nèi)存小就稱為輕量級(jí)的對(duì)象。Session的緩存被稱為hibernate的第一級(jí)緩存。SessionFactory的外置緩存稱為hibernate的二級(jí)緩存。這兩個(gè)緩存都位于長(zhǎng)久層，它們存放的都是數(shù)據(jù)庫(kù)數(shù)據(jù)的拷貝。SessionFactory的內(nèi)置緩存存放元數(shù)據(jù)和預(yù)定義SQL,SessionFactory的內(nèi)置緩存是只讀緩存。Session緩存的三大作用：1，削減數(shù)據(jù)庫(kù)的訪問頻率，提高訪問性能。2，保證緩存中的對(duì)象與數(shù)據(jù)庫(kù)同步，位于緩存中的對(duì)象稱為長(zhǎng)久化對(duì)象。3，當(dāng)長(zhǎng)久化對(duì)象之間存在關(guān)聯(lián)時(shí)，Session保證不消滅對(duì)象圖的死鎖。Session如何推斷長(zhǎng)久化對(duì)象的狀態(tài)的轉(zhuǎn)變呢？Session加載對(duì)象后會(huì)為對(duì)象值類型的屬性復(fù)制一份快照。當(dāng)Session清理緩存時(shí)，比較當(dāng)前對(duì)象和它的快照就可以知道那些屬性發(fā)生了變化。Session什么時(shí)候清理緩存？1，commit方法被調(diào)用時(shí)2，查詢時(shí)會(huì)清理緩存，保證查詢結(jié)果能反映對(duì)象的最狀態(tài)。3，顯示的調(diào)用session的flush方法。session清理緩存的特例：當(dāng)對(duì)象使用native生成器時(shí)會(huì)馬上清理緩存向數(shù)據(jù)庫(kù)中插入記錄。hibernate一級(jí)緩存和二級(jí)緩存的區(qū)分Hibernate供給了兩級(jí)緩存，第一級(jí)是SessionSession對(duì)象的生命周期通常對(duì)OID。其次級(jí)緩存是一個(gè)可插拔的的緩存插件，它是由 SessionFactory負(fù)責(zé)治理。由于SessionFactory對(duì)象的生命周期和應(yīng)用程序的整個(gè)過程對(duì)應(yīng)，因此其次級(jí)緩存是進(jìn)程范圍或者集群范圍的緩存。這個(gè)緩存中存放的對(duì)象的松散數(shù)據(jù)。其次級(jí)對(duì)象有可能消滅并發(fā)問題，因此需要承受適當(dāng)?shù)牟l(fā)訪問策略該策略為被緩存的數(shù)據(jù)供給了事務(wù)隔離級(jí)別緩存適配器用于把具體的緩存實(shí)現(xiàn)軟件與Hibernate集成。其次級(jí)緩存是可選的，可以在每個(gè)類或每個(gè)集合的粒度上配置其次級(jí)緩存。Hibernate的二級(jí)緩存策略的一般過程如下：select*fromtable_namewhere?.〔選擇全部字段〕這樣的SQL語句查詢數(shù)據(jù)庫(kù)，一次獲得全部的數(shù)據(jù)對(duì)象。把獲得的全部數(shù)據(jù)對(duì)象依據(jù)ID放入到其次級(jí)緩存中。當(dāng)HibernateID訪問數(shù)據(jù)對(duì)象的時(shí)候，首先從Session一級(jí)緩存中查；查不到，假設(shè)配置了二級(jí)緩存，那么從二級(jí)緩存中查；查不到，再查詢數(shù)據(jù)庫(kù)，把結(jié)果依據(jù)ID放入到緩存。刪除、更、增加數(shù)據(jù)的時(shí)候，同時(shí)更緩存。Hibernate的二級(jí)緩存策略，是針對(duì)于ID查詢的緩存策略，對(duì)于條件查詢則毫無作用。為此，Hibernate供給了針對(duì)條件查詢的Query緩存。Hibernate的Query緩存策略的過程如下：Hibernate首先依據(jù)這些信息組成一個(gè)QueryKey，QueryKey包括條件查詢的懇求一般信息：SQL,SQL需要的參數(shù)，記錄范圍〔起始位置rowStart，最大記錄個(gè)數(shù)maxRows)，等。Hibernate依據(jù)這個(gè)QueryKeyQuery緩存中查找對(duì)應(yīng)的結(jié)果列表。假設(shè)存在，那QueryKeyQuery緩存中。QueryKeySQL涉及到一些表名，假設(shè)這些表的任何數(shù)據(jù)發(fā)生修改、刪除、增加等操作，這些相關(guān)的QueryKey都要從緩存中清空。1什么是單點(diǎn)登陸單點(diǎn)登錄en，簡(jiǎn)稱為O，是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO的定義是在多個(gè)應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問全部相互信任的應(yīng)用系統(tǒng)。單點(diǎn)登錄的機(jī)制也一樣，如以下圖所示，當(dāng)用戶第一次訪問應(yīng)用系統(tǒng)1的時(shí)候，由于還沒有登錄，會(huì)被引導(dǎo)到認(rèn)證系統(tǒng)中進(jìn)展登錄〔1；依據(jù)用戶供給的登錄信息，認(rèn)證系統(tǒng)進(jìn)展身份效驗(yàn)，假設(shè)〔2〔3，5〕就會(huì)將這個(gè)ticket帶上，作為自己認(rèn)證的憑據(jù)，應(yīng)用系統(tǒng)承受到懇求之后會(huì)把ticket送到認(rèn)證系統(tǒng)進(jìn)展效驗(yàn)，檢查t的合法性〔4，6。假設(shè)通過效驗(yàn)，用戶就可以在不用再次登23了。全部應(yīng)用系統(tǒng)共享一個(gè)身份認(rèn)證系統(tǒng)。統(tǒng)一的認(rèn)證系統(tǒng)是SSO的前提之一。認(rèn)證系統(tǒng)的主要功能是將用戶的登錄信息和用戶信息庫(kù)相比較，對(duì)用戶進(jìn)展登錄認(rèn)證；認(rèn)證成功后，認(rèn)證系統(tǒng)應(yīng)當(dāng)生成統(tǒng)一的認(rèn)證標(biāo)志〔ticket〕，返還ticket進(jìn)展效驗(yàn)，推斷其有效性。全部應(yīng)用系統(tǒng)能夠識(shí)別和提取ticket信息要實(shí)現(xiàn)SSO的功能，讓用戶只登錄一次，就必需讓應(yīng)用系統(tǒng)能夠識(shí)別已經(jīng)登錄過的用戶。應(yīng)用系統(tǒng)應(yīng)當(dāng)能對(duì)ticket進(jìn)展識(shí)別和提取，通過與認(rèn)證系統(tǒng)的通訊，能自動(dòng)推斷當(dāng)前用戶是否登錄過，從而完成單點(diǎn)登錄的功能。接口和抽象類的區(qū)分 類來說，對(duì)于抽象類來說，屬于“是”的關(guān)系；而接口是定義行為標(biāo)準(zhǔn)，因此對(duì)于實(shí)現(xiàn)接口的子類來說，相對(duì)于接口來說，是“行為需要依據(jù)接口來完成接口來說，其中所定義的方法都不能給出實(shí)現(xiàn)局部。說，在繼承類中必需要給出相應(yīng)的方法和屬性實(shí)現(xiàn)。則需要修改繼承類，供給定義的方法。如下給出兩者的簡(jiǎn)潔比照表格。接口抽象類多繼承支持不支持類型限制沒有有，只能是引用類型方法實(shí)現(xiàn)繼承類型中必需給出方法實(shí)現(xiàn)繼承類中可以不給出擴(kuò)展性比較麻煩相比照較敏捷多層繼承比較麻煩，需要借助虛函數(shù)比較敏捷籠統(tǒng)點(diǎn)說：接口=定義了要做的全部事情，但自己啥也不干抽象類=做了局部工作，剩下的他不干了，等后來人連續(xù)完成內(nèi)存泄漏例如1Object對(duì)象，并將所申請(qǐng)的對(duì)象放入一個(gè)Vector中，假設(shè)僅僅釋放引用本身，那么Vector仍舊引用該對(duì)象，所以這個(gè)對(duì)象對(duì)GC來說是不行回收的。因此，假設(shè)對(duì)象參加到Vector后，還必需從Vector中刪除，最簡(jiǎn)潔的方法就是將Vector對(duì)象設(shè)置為null。Vectorv=newVector(10);for(inti=1;i<100;i++){Objecto=newObject;v.add(o);o=null;}//此時(shí)，全部的Object對(duì)象都沒有被釋放，由于變量v引用這些對(duì)象。實(shí)際上無用，而還被引用的對(duì)象，GC就無能為力了〔GC認(rèn)為它還有用〕，這一點(diǎn)是導(dǎo)致內(nèi)存泄漏最重要的緣由。(1)假設(shè)要釋放對(duì)象，就必需使其的引用記數(shù)為0，只有那些不再被引用的對(duì)象才能被釋放，(2)程序員無須治理對(duì)象空間具體的安排和釋放過程，但必需要關(guān)注被釋放對(duì)象的引用記數(shù)0；(3)一個(gè)對(duì)象可能被其他對(duì)象引用的過程的幾種：a.直接賦值，如上例中的A.a=E；b.通過參數(shù)傳遞，例如publicvoidaddObject(ObjectE)；c.其它一些狀況如系統(tǒng)調(diào)用等。簡(jiǎn)潔引起內(nèi)存泄漏的幾大緣由靜態(tài)集合類像HashMap、Vector等靜態(tài)集合類的使用最簡(jiǎn)潔引起內(nèi)存泄漏，由于這些靜態(tài)變量的生命周期與應(yīng)用程序全都，如例如1，假設(shè)該Vector是靜態(tài)的，那么它將始終存在，而其中全部的Object對(duì)象也不能被釋放，由于它們也將始終被該Vector引用著。監(jiān)聽器java編程中，我們都需要和監(jiān)聽器打交道，通常一個(gè)應(yīng)用當(dāng)中會(huì)用到很多監(jiān)聽器，我們會(huì)調(diào)用一個(gè)控件的諸如addXXXListener候卻沒有記住去刪除這些監(jiān)聽器，從而增加了內(nèi)存泄漏的時(shí)機(jī)。物理連接一些物理連接，比方數(shù)據(jù)庫(kù)連接和網(wǎng)絡(luò)連接，除非其顯式的關(guān)閉了連接，否則是不會(huì)自動(dòng)被GC回收的。Java數(shù)據(jù)庫(kù)連接一般用DataSource.getConnection來創(chuàng)立，當(dāng)不再使用時(shí)必需用Close方法來釋放，由于這些連接是獨(dú)立于JVM的。對(duì)于Resultset和StatementConnectionConnection在Connection一旦回收，ResultsetStatement對(duì)象就會(huì)馬上為NULL。但是假設(shè)使用連接池，狀況就不一樣了，除了要顯式地關(guān)閉連接，還必需顯式地關(guān)閉ResultsetStatement對(duì)象〔關(guān)閉其中一個(gè)，另外一個(gè)也會(huì)關(guān)閉〕，否則就會(huì)造成大量的Statement對(duì)象無法釋放，從而引起內(nèi)存泄漏。優(yōu)缺點(diǎn)1.strutsstruts框架具有組件的模塊化，敏捷性和重用性的優(yōu)點(diǎn)，同時(shí)簡(jiǎn)化了基于MVCweb應(yīng)用程序的開發(fā)。優(yōu)點(diǎn)：StrutsTomcat、Turbine等諸多Apache工程一樣，是開源軟件，這是它的一大優(yōu)點(diǎn)。使開發(fā)者能更深入的了解其內(nèi)部實(shí)現(xiàn)機(jī)制。除此之外，Struts的優(yōu)點(diǎn)主要集中表達(dá)在兩個(gè)方面：TaglibTaglibStruts的標(biāo)記庫(kù)，敏捷動(dòng)用，能大大提高開發(fā)效率。另外，就目前國(guó)內(nèi)的JSP開發(fā)者而言，除了使用JSP自帶的常用標(biāo)記外，很少開發(fā)自己的標(biāo)記，或許Struts是一個(gè)很好的起點(diǎn)。的好處。尤其是當(dāng)另一批開發(fā)者接手這個(gè)工程時(shí)，這種優(yōu)勢(shì)表達(dá)得更加明顯。struts〔很多成功案例HTML標(biāo)簽格外優(yōu)秀缺點(diǎn)：Taglib是Struts的一大優(yōu)勢(shì)，但對(duì)于初學(xué)者而言，卻需要一個(gè)持續(xù)學(xué)習(xí)的過程，甚至還會(huì)打亂你網(wǎng)頁編寫的習(xí)慣，但是，當(dāng)你習(xí)慣了它時(shí)，你會(huì)覺得它真的很棒。StrutsMVC的ControllerActionForms使用不便、無法進(jìn)展單元測(cè)試〔StrutsTestCase只能用于集成〕【IT168技術(shù)文檔】Struts跟Tomcat、Turbine等諸多Apache工程一樣，是開源軟件，這是它的一大優(yōu)點(diǎn)。使開發(fā)者能更深入的了解其內(nèi)部實(shí)現(xiàn)機(jī)制。Struts開放源碼框架的創(chuàng)立是為了使開發(fā)者在構(gòu)建基于JavaServlet和JavaServers〔JSP〕技術(shù)的Web應(yīng)用時(shí)更加簡(jiǎn)潔Struts框架為開放者供給了一個(gè)統(tǒng)一的標(biāo)準(zhǔn)框架通過使用Struts作為根底，開發(fā)者能夠更專注于應(yīng)用程序的商業(yè)規(guī)律。Struts框架本身是使用Java Servlet和JavaServers 技術(shù)的一種Model-View-Controller〔MVC〕實(shí)現(xiàn).具體來講,Struts的優(yōu)點(diǎn)有:實(shí)現(xiàn)MVC模式，構(gòu)造清楚,使開發(fā)者只關(guān)注業(yè)務(wù)規(guī)律的實(shí)現(xiàn).有豐富的tag可以用,Struts的標(biāo)記庫(kù)(Taglib)JSPJSP記，或許Struts是一個(gè)很好的起點(diǎn)。頁面導(dǎo)航.頁面導(dǎo)航將是今后的一個(gè)進(jìn)展方向，事實(shí)上，這樣做，使系統(tǒng)的脈絡(luò)更加清楚的好處。尤其是當(dāng)另一批開發(fā)者接手這個(gè)工程時(shí)，這種優(yōu)勢(shì)表達(dá)得更加明顯。供給Exception處理機(jī)制.數(shù)據(jù)庫(kù)鏈接池治理I18N缺點(diǎn):一、轉(zhuǎn)到展現(xiàn)層時(shí)，需要配置forward，每一次轉(zhuǎn)到展現(xiàn)層，信任大多數(shù)都是直接轉(zhuǎn)到j(luò)sp，而涉及到轉(zhuǎn)向，需要配置forward，假設(shè)有十個(gè)展現(xiàn)層的jsp，需要配置十次struts，而且還不包括有時(shí)候名目、文件變更，需要重修改forward，留意，每次修改配置之后，要求重部署整個(gè)工程，而tomcate這樣的效勞器，還必需重啟動(dòng)效勞器，假設(shè)業(yè)務(wù)變更簡(jiǎn)單的系統(tǒng)，大家可以想象一下，我的苦惱有多大。二、Struts的Action必需是thread－safeaction用到的全部的資源都必需統(tǒng)一同步，這個(gè)就引起了線程安全的問題。三、測(cè)試不便利.Struts的每個(gè)Action都同WebWeb容器，單元測(cè)試也很難實(shí)現(xiàn)。不過有一個(gè)JunitStrutsTestCase可以實(shí)現(xiàn)它的單元測(cè)試。四、類型的轉(zhuǎn)換.StrutsFormBean把全部的數(shù)據(jù)都作為String類型，它可以使用工具Commons-Beanutils進(jìn)展類型轉(zhuǎn)化。但它的轉(zhuǎn)化都是在Class級(jí)別，而且轉(zhuǎn)化的類型是不行配置的。類型轉(zhuǎn)化時(shí)的錯(cuò)誤信息返回給用戶也是格外困難的。五、對(duì)Servlet.Struts處理Action時(shí)必需要依靠ServletRequest和ServletResponse，全部它擺脫不了Servlet容器。六、前端表達(dá)式語言方面.Struts集成了JSTL，所以它主要使用JSTL的表達(dá)式語言來獵取數(shù)據(jù)?？墒荍STL的表達(dá)式語言在Collection和索引屬性方面處理顯得很弱。七、對(duì)Action執(zhí)行的掌握困難.Struts創(chuàng)立一個(gè)Action，假設(shè)想掌握它的執(zhí)行挨次將會(huì)格外困難。甚至你要重去寫Servlet來實(shí)現(xiàn)你的這個(gè)功能需求。八、對(duì)Action執(zhí)行前和后的處理.Struts處理Action的時(shí)候是基于class的hierarchies，很難在action處理前和后進(jìn)展操作。九、對(duì)大事支持不夠.在struts中，實(shí)際是一個(gè)表單Form對(duì)應(yīng)一個(gè)Action類(或DispatchAction)，換一句話說：在Struts中實(shí)際是一個(gè)表單只能對(duì)應(yīng)一個(gè)大事，struts這種大事方式稱為applicationevenapplicationevent和componenteventStrutsActionForm是一種對(duì)象，它代表了一種應(yīng)用，這個(gè)對(duì)象中至少包含幾個(gè)字段，這些字段是Jsp頁面表單中的input字段，由于一個(gè)表單對(duì)應(yīng)一個(gè)大事，所以，純使用Struts就不太可能，固然通過結(jié)合JavaScript也是可以轉(zhuǎn)彎實(shí)現(xiàn)的。HibernateHibernate是一個(gè)開放源代碼的對(duì)象關(guān)系映射框架，它對(duì)JDBC進(jìn)展了格外輕量級(jí)的對(duì)象封裝，使得Java程序員可以隨心所欲的使用對(duì)象編程思維來操縱數(shù)據(jù)庫(kù)。Hibernate可以應(yīng)用在任何使用JDBC的場(chǎng)合，既可以在Java的客戶端程序有用，也可以在Servlet/JSPWeb應(yīng)用中使用，最具革命意義的是，HibernateEJBJ2EE架構(gòu)中取代CMP，完成數(shù)據(jù)長(zhǎng)久化的重任。修改應(yīng)用的其余局部使之適應(yīng)這種轉(zhuǎn)變的代價(jià)將是格外巨大的。Hibernate適時(shí)的填補(bǔ)了這一空白，它為Java應(yīng)用供給了一個(gè)易用的、高效率的對(duì)象關(guān)系映射框架。hibernate是個(gè)輕量級(jí)的長(zhǎng)久性框架，功能卻格外豐富。優(yōu)點(diǎn)：a.Hibernate使用Java反射機(jī)制而不是字節(jié)碼增加程序來實(shí)現(xiàn)透亮性。b.Hibernate的性能格外好，由于它是個(gè)輕量級(jí)框架。映射的敏捷性很精彩。c.它支持各種關(guān)系數(shù)據(jù)庫(kù)，從一對(duì)一到多對(duì)多的各種簡(jiǎn)單關(guān)系。缺點(diǎn)：它限制您所使用的對(duì)象模型。(例如，一個(gè)長(zhǎng)久性類不能映射到多個(gè)表)其獨(dú)有的界面和可憐的市場(chǎng)份額也讓人擔(dān)憂，盡管如此，Hibernate還是以其強(qiáng)大的進(jìn)展動(dòng)力減輕了這些風(fēng)險(xiǎn)。Hibernate這樣有市場(chǎng)沖擊力。Hibernate而感到不快，而是由于帖子里面的觀點(diǎn)實(shí)在讓我覺得荒唐。不管覺得Hibernate好也吧，不好也吧，我唯一覺HibernateTSS上有一個(gè)關(guān)于e的te作者n和JDOCTOJDOHibernate有過一些劇烈的爭(zhēng)論，我曾經(jīng)急躁的看了一遍，仍HibernateHibernate沒有一GUI的配置工具，沒有商業(yè)公司支持，沒有標(biāo)準(zhǔn)化等等這些站不住腳的理由。補(bǔ)充幾點(diǎn)我的意見：一、HibernateJDBC的輕量級(jí)的對(duì)象封裝，它是一個(gè)獨(dú)立的對(duì)象長(zhǎng)久層框架，和AppServerEJB沒有什么必定的聯(lián)系。HibernateJDBC可以使用的場(chǎng)合，Java應(yīng)用程序的數(shù)據(jù)庫(kù)訪問代碼，DAOBMP里面的訪問HibernateEB即彼的關(guān)系。HibernateJDBCHibernateJDBC驅(qū)動(dòng)，和數(shù)據(jù)庫(kù)都有肯定的關(guān)系，但是和使用它的JavaAppServer沒有任何關(guān)系，也不存在兼容性問題。三、HibernateEntityBeanJ2EE工程的框架中才能比較。并且即使是放在軟件整體框架中來看，Hibernate也是做為JDBC的替代者消滅EntityBean的替代者消滅的，讓我再列一次我已經(jīng)列n次的框架構(gòu)造：傳統(tǒng)的架構(gòu)：SessionBean<->EntityBean<->DB為了解決性能障礙的替代架構(gòu)：SessionBean<->DAO<->JDBC<->DB使用Hibernate來提高上面架構(gòu)的開發(fā)效率的架構(gòu)：SessionBean<->DAO<->Hibernate<->DB3個(gè)架構(gòu)來分析：1、內(nèi)存消耗：承受JDBC2無疑是最省內(nèi)存的，Hibernate3次之，EB的1最差。2、運(yùn)行效率：假設(shè)JDBC的代碼寫的格外優(yōu)化，那么JDBC架構(gòu)運(yùn)行效率最高，但是實(shí)際工程中，這一點(diǎn)幾乎做不到，這需要程序員格外精通JDBC，運(yùn)用Batch語句，調(diào)整PreapredStatementBatchSizeFetchSize等參數(shù)，以及在必要的狀況下承受結(jié)cache等等。而一般狀況下程序員是做不到這一點(diǎn)的。因此Hibernate架構(gòu)表現(xiàn)出最快的運(yùn)行效率。EB的架構(gòu)效率會(huì)差的很遠(yuǎn)。3JBuilder的支持下以及簡(jiǎn)潔的工程，EB架構(gòu)開發(fā)效率最高，JDBC次e效率高的驚人，JDBCEB架構(gòu)很可能會(huì)失敗。4、分布式，安全檢查，集群，負(fù)載均衡的支持SBFacade，3個(gè)架構(gòu)沒有區(qū)分。四、EBHibernate學(xué)習(xí)難度在哪里？EBXMLEBEJB設(shè)計(jì)模式來避開性能問題，需要學(xué)習(xí)AppServerEBEBEB的開發(fā)工作，程序員的大局部精力都被放到了EB的性能問題上了，反而沒有更多的精力關(guān)注本身就主要投入精力去考慮的對(duì)象長(zhǎng)久層的設(shè)計(jì)上來。HibernateHibernateHibernateHibernate太敏捷了。EB來實(shí)現(xiàn)長(zhǎng)久層的時(shí)候，你會(huì)覺察EB實(shí)在是太笨拙了，笨拙到你根本沒有什么可選擇哪個(gè)方案，由于只有唯一的方案擺在你面前，你只能這么做，沒得選擇。Hibernate相反，它太敏捷了，一樣的問題，你至少可以設(shè)計(jì)出十幾種方案來解決，所以犯難？集合屬性可以用Set，可以用List，還可以用Bag，到底哪個(gè)效率高，你犯難不犯難？查詢可以用iterator，可以用list，哪個(gè)好，有什么區(qū)分？你犯難不犯難？復(fù)合主鍵你可以直接在hbm里面配置，也可以自定義CustomerType，哪種比較好些？你犯難不為1:1的對(duì)象，在什么狀況下用哪種方案比較好，你犯難不犯難？不出來