J2EE三大框架面試的常見問題

1、ssh優(yōu)缺點1.strutsstruts框架具有組件的模塊化，靈活性和重用性的優(yōu)點，同時簡化了基于mvc的web應用程序的開發(fā)。優(yōu)點：struts跟tomcat、turbine等諸多apache項目一樣，是開源軟件，這是它的一大優(yōu)點。使開發(fā)者能更深入的了解其內部實現(xiàn)機制。除此之外，struts的優(yōu)點主要集中體現(xiàn)在兩個方面：taglib和頁面導航。taglib是struts的標記庫，靈活動用，能大大提高開發(fā)效率。另外，就目前國內的jsp開發(fā)者而言，除了使用jsp自帶的常用標記外，很少開發(fā)自己的標記，或許struts是一個很好的起點。關于頁面導航，我認為那將是今后的一個發(fā)展方向，事實上，這樣做，使

2、系統(tǒng)的脈絡更加清晰。通過一個配置文件，即可把握整個系統(tǒng)各部分之間的聯(lián)系，這對于后期的維護有著莫大的好處。尤其是當另一批開發(fā)者接手這個項目時，這種優(yōu)勢體現(xiàn)得更加明顯。另外，struts是業(yè)界標準（很多成功案例），學習資源豐富，html標簽非常優(yōu)秀缺點：taglib是struts的一大優(yōu)勢，但對于初學者而言，卻需要一個持續(xù)學習的過程，甚至還會打亂你網(wǎng)頁編寫的習慣，但是，當你習慣了它時，你會覺得它真的很棒。struts將mvc的controller一分為三，在獲得結構更加清晰的同時，也增加了系統(tǒng)的復雜度。actionforms使用不便、無法進行單元測試（strutstestcase只能用于集成） s

3、truts跟tomcat、turbine等諸多apache項目一樣，是開源軟件，這是它的一大優(yōu)點。使開發(fā)者能更深入的了解其內部實現(xiàn)機制。 struts開放源碼框架的創(chuàng)建是為了使開發(fā)者在構建基于java servlet和javaserver pages（jsp）技術的web應用時更加容易。struts框架為開放者提供了一個統(tǒng)一的標準框架，通過使用struts作為基礎，開發(fā)者能夠更專注于應用程序的商業(yè)邏輯。struts框架本身是使用java servlet和javaserver pages技術的一種model-view-controller（mvc）實現(xiàn). 具體來講,struts的優(yōu)點有: 1.

4、實現(xiàn)mvc模式，結構清晰,使開發(fā)者只關注業(yè)務邏輯的實現(xiàn). 2. 有豐富的tag可以用 ,struts的標記庫(taglib)，如能靈活動用，則能大大提高開發(fā)效率。另外，就目前國內的jsp開發(fā)者而言，除了使用jsp自帶的常用標記外，很少開發(fā)自己的標記，或許struts是一個很好的起點。 3. 頁面導航.頁面導航將是今后的一個發(fā)展方向，事實上，這樣做，使系統(tǒng)的脈絡更加清晰。通過一個配置文件，即可把握整個系統(tǒng)各部分之間的聯(lián)系，這對于后期的維護有著莫大的好處。尤其是當另一批開發(fā)者接手這個項目時，這種優(yōu)勢體現(xiàn)得更加明顯。 4. 提供exception處理機制 . 5. 數(shù)據(jù)庫鏈接池管理 6. 支持i18

5、n 缺點: 一、 轉到展示層時，需要配置forward，每一次轉到展示層，相信大多數(shù)都是直接轉到jsp，而涉及到轉向，需要配置forward，如果有十個展示層的jsp，需要配置十次struts，而且還不包括有時候目錄、文件變更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整個項目，而tomcate這樣的服務器，還必須重新啟動服務器，如果業(yè)務變更復雜頻繁的系統(tǒng)，這樣的操作簡單不可想象?，F(xiàn)在就是這樣，幾十上百個人同時在線使用我們的系統(tǒng)，大家可以想象一下，我的煩惱有多大。 二、 struts 的action必需是threadsafe方式，它僅僅允許一個實例去處理所有的請求。所以a

6、ction用到的所有的資源都必需統(tǒng)一同步，這個就引起了線程安全的問題。 三、 測試不方便. struts的每個action都同web層耦合在一起，這樣它的測試依賴于web容器，單元測試也很難實現(xiàn)。不過有一個junit的擴展工具struts testcase可以實現(xiàn)它的單元測試。 四、 類型的轉換. struts的formbean把所有的數(shù)據(jù)都作為string類型，它可以使用工具commons-beanutils進行類型轉化。但它的轉化都是在class級別，而且轉化的類型是不可配置的。類型轉化時的錯誤信息返回給用戶也是非常困難的。 五、 對servlet的依賴性過強. struts處理actio

7、n時必需要依賴servletrequest 和servletresponse，所有它擺脫不了servlet容器。 六、 前端表達式語言方面.struts集成了jstl，所以它主要使用jstl的表達式語言來獲取數(shù)據(jù)。可是jstl的表達式語言在collection和索引屬性方面處理顯得很弱。 七、 對action執(zhí)行的控制困難. struts創(chuàng)建一個action，如果想控制它的執(zhí)行順序將會非常困難。甚至你要重新去寫servlet來實現(xiàn)你的這個功能需求。 八、 對action 執(zhí)行前和后的處理. struts處理action的時候是基于class的hierarchies，很難在action處理前和后

8、進行操作。 九、 對事件支持不夠. 在struts中，實際是一個表單form對應一個action類(或dispatchaction)，換一句話說：在struts中實際是一個表單只能對應一個事件，struts這種事件方式稱為application event，application event和component event相比是一種粗粒度的事件。 struts重要的表單對象actionform是一種對象，它代表了一種應用，這個對象中至少包含幾個字段，這些字段是jsp頁面表單中的input字段，因為一個表單對應一個事件，所以，當我們需要將事件粒度細化到表單中這些字段時，也就是說，一個字段對應一個

9、事件時，單純使用struts就不太可能，當然通過結合javascript也是可以轉彎實現(xiàn)的。2hibernatehibernate是一個開放源代碼的對象關系映射框架，它對jdbc進行了非常輕量級的對象封裝，使得java程序員可以隨心所欲的使用對象編程思維來操縱數(shù)據(jù)庫。hibernate可以應用在任何使用jdbc的場合，既可以在java的客戶端程序實用，也可以在servlet/jsp的web應用中使用，最具革命意義的是，hibernate可以在應用ejb的j2ee架構中取代cmp，完成數(shù)據(jù)持久化的重任。大多數(shù)開發(fā)機構經(jīng)常采取創(chuàng)建各自獨立的數(shù)據(jù)持久層。一旦底層的數(shù)據(jù)結構發(fā)生改變，那么修改應用的其余

10、部分使之適應這種改變的代價將是十分巨大的。hibernate適時的填補了這一空白，它為java應用提供了一個易用的、高效率的對象關系映射框架。hibernate是個輕量級的持久性框架，功能卻非常豐富。優(yōu)點：a.? hibernate 使用 java 反射機制 而不是字節(jié)碼增強程序來實現(xiàn)透明性。b.? ?hibernate 的性能非常好，因為它是個輕量級框架。 映射的靈活性很出色。c.? 它支持各種關系數(shù)據(jù)庫，從一對一到多對多的各種復雜關系。 缺點：它限制您所使用的對象模型。(例如，一個持久性類不能映射到多個表)其獨有的界面和可憐的市場份額也讓人不安，盡管如此，hibernate 還是以其強大的

11、發(fā)展動力減輕了這些風險。其他的開源持久性框架也有一些，不過都沒有 hibernate 這樣有市場沖擊力。上面回貼情緒有點激動，希望諒解，我不是因為有人批評hibernate而感到不快，而是因為帖子里面的觀點實在讓我覺得荒謬。不管覺得hibernate好也吧，不好也吧，我唯一覺得遺憾的是，在中文論壇里面找不到一個對hibernate的真正高水平的評價。在tss上有一個關于hibernate的hot thread，跟了幾百貼，其中包括hibernate作者gavin和lido jdo的cto，對于jdo和hibernate有過一些激烈的爭論，我曾經(jīng)耐心的看了一遍，仍然沒有發(fā)現(xiàn)針對hibernate

12、真正有力的攻擊，那些所謂的攻擊無非針對hibernate沒有一個gui的配置工具，沒有商業(yè)公司支持，沒有標準化等等這些站不住腳的理由。補充幾點我的意見：一、hibernate是jdbc的輕量級的對象封裝，它是一個獨立的對象持久層框架，和app server，和ejb沒有什么必然的聯(lián)系。hibernate可以用在任何jdbc可以使用的場合，例如java應用程序的數(shù)據(jù)庫訪問代碼，dao接口的實現(xiàn)類，甚至可以是bmp里面的訪問數(shù)據(jù)庫的代碼。從這個意義上來說，hibernate和eb不是一個范疇的東西，也不存在非此即彼的關系。二、hibernate是一個和jdbc密切關聯(lián)的框架，所以hibernate

13、的兼容性和jdbc驅動，和數(shù)據(jù)庫都有一定的關系，但是和使用它的java程序，和app server沒有任何關系，也不存在兼容性問題。三、hibernate不能用來直接和entity bean做對比，只有放在整個j2ee項目的框架中才能比較。并且即使是放在軟件整體框架中來看，hibernate也是做為jdbc的替代者出現(xiàn)的，而不是entity bean的替代者出現(xiàn)的，讓我再列一次我已經(jīng)列n次的框架結構：傳統(tǒng)的架構：1) session bean entity bean db為了解決性能障礙的替代架構：2) session bean dao jdbc db使用hibernate來提高上面架構的開發(fā)

14、效率的架構：3) session bean dao hibernate db 就上面3個架構來分析：1、內存消耗：采用jdbc的架構2無疑是最省內存的，hibernate的架構3次之，eb的架構1最差。2、運行效率：如果jdbc的代碼寫的非常優(yōu)化，那么jdbc架構運行效率最高，但是實際項目中，這一點幾乎做不到，這需要程序員非常精通jdbc，運用batch語句，調整preapredstatement的batch size和fetch size等參數(shù)，以及在必要的情況下采用結果集cache等等。而一般情況下程序員是做不到這一點的。因此hibernate架構表現(xiàn)出最快的運行效率。eb的架構效率會差的

15、很遠。3、開發(fā)效率：在有jbuilder的支持下以及簡單的項目，eb架構開發(fā)效率最高，jdbc次之，hibernate最差。但是在大的項目，特別是持久層關系映射很復雜的情況下，hibernate效率高的驚人，jdbc次之，而eb架構很可能會失敗。4、分布式，安全檢查，集群，負載均衡的支持由于有sb做為facade，3個架構沒有區(qū)別。四、eb和hibernate學習難度在哪里？eb的難度在哪里？不在復雜的xml配置文件上，而在于eb運用稍微不慎，就有嚴重的性能障礙。所以難在你需要學習很多ejb設計模式來避開性能問題，需要學習app server和eb的配置來優(yōu)化eb的運行效率。做eb的開發(fā)工作，

16、程序員的大部分精力都被放到了eb的性能問題上了，反而沒有更多的精力關注本身就主要投入精力去考慮的對象持久層的設計上來。hibernate難在哪里？不在hibernate本身的復雜，實際上hibernate非常的簡單，難在hibernate太靈活了。當你用eb來實現(xiàn)持久層的時候，你會發(fā)現(xiàn)eb實在是太笨拙了，笨拙到你根本沒有什么可以選擇的余地，所以你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮選擇哪個方案，因為只有唯一的方案擺在你面前，你只能這么做，沒得選擇。hibernate相反，它太靈活了，相同的問題，你至少可以設計出十幾種方案來解決，所以特別的犯難，究竟用這個，還是用那個呢？

17、這些方案之間到底有什么區(qū)別呢？他們的運行原理有什么不同？運行效率哪個比較好？光是主鍵生成，就有七八種方案供你選擇，你為難不為難？集合屬性可以用set，可以用list，還可以用bag，到底哪個效率高，你為難不為難？查詢可以用iterator，可以用list，哪個好，有什么區(qū)別？你為難不為難？復合主鍵你可以直接在hbm里面配置，也可以自定義customertype，哪種比較好些？你為難不為難？對于一個表，你可以選擇單一映射一個對象，也可以映射成父子對象，還可以映射成兩個1:1的對象，在什么情況下用哪種方案比較好，你為難不為難？這個列表可以一直開列下去，直到你不想再看下去為止。當你面前擺著無數(shù)的眼花

18、繚亂的方案的時候，你會覺得幸福呢？還是悲哀呢？如果你是一個負責的程序員，那么你一定會仔細研究每種方案的區(qū)別，每種方案的效率，每種方案的適用場合，你會覺得你已經(jīng)陷入進去拔不出來了。如果是用eb，你第一秒種就已經(jīng)做出了決定，根本沒得選擇，比如說集合屬性，你只能用collection，如果是hibernate，你會在bag，list和set之間來回猶豫不決，甚至搞不清楚的話，程序都沒有辦法寫。3 spring它是一個開源的項目，而且目前非?；钴S；它基于ioc（inversion of control，反向控制）和aop的構架多層j2ee系統(tǒng)的框架，但它不強迫你必須在每一層 中必須使用spring，因

19、為它模塊化的很好，允許你根據(jù)自己的需要選擇使用它的某一個模塊；它實現(xiàn)了很優(yōu)雅的mvc，對不同的數(shù)據(jù)訪問技術提供了統(tǒng)一的 接口，采用ioc使得可以很容易的實現(xiàn)bean的裝配，提供了簡潔的aop并據(jù)此實現(xiàn)transcation managment，等等優(yōu)點 a. spring能有效地組織你的中間層對象，不管你是否選擇使用了ejb。如果你僅僅使用了struts或其他為j2ee的 api特制的framework，spring致力于解決剩下的問題。b. spring能消除在許多工程中常見的對singleton的過多使用。根據(jù)我的經(jīng)驗，這是一個很大的問題，它降低了系統(tǒng)的可測試性和面向對象的程度。 c. 通

20、過一種在不同應用程序和項目間一致的方法來處理配置文件，spring能消除各種各樣自定義格式的屬性文件的需要。曾經(jīng)對某個類要尋找的是哪個方法的哪個的屬性項或系統(tǒng)屬性感到不解，為此不得不去讀javadoc甚至源編碼？有了spring，你僅僅需要看看類的javabean屬性。inversion of control的使用（在下面討論）幫助完成了這種簡化。 d. 通過把對接口編程而不是對類編程的代價幾乎減少到?jīng)]有，spring能夠促進養(yǎng)成好的編程習慣。 e. spring被設計為讓使用它創(chuàng)建的應用盡可能少的依賴于他的apis。在spring應用中的大多數(shù)業(yè)務對象沒有依賴于spring。 f. 使用sp

21、ring構建的應用程序易于單元測試。 g. spring能使ejb的使用成為一個實現(xiàn)選擇,而不是應用架構的必然選擇。你能選擇用pojos或local ejbs來實現(xiàn)業(yè)務接口，卻不會影響調用代碼。 h. spring幫助你解決許多問題而無需使用ejb。spring能提供一種ejb的替換物，它們適用于許多web應用。例如，spring能使用aop提供聲明性事務管理而不通過ejb容器，如果你僅僅需要與單個數(shù)據(jù)庫打交道，甚至不需要一個jta實現(xiàn)。 i. ?spring為數(shù)據(jù)存取提供了一個一致的框架,不論是使用的是jdbc還是o/r mapping產品（如hibernate）。 spring確實使你能通

22、過最簡單可行的解決辦法來解決你的問題。而這是有有很大價值的。缺點：使用人數(shù)不多、jsp中要寫很多代碼、控制器過于靈活，缺少一個公用控制器ssh面試精華 hibernate工作原理及為什么要用？原理：1.讀取并解析配置文件2.讀取并解析映射信息，創(chuàng)建sessionfactory3.打開sesssion4.創(chuàng)建事務transation5.持久化操作6.提交事務7.關閉session8.關閉sesstionfactory為什么要用：1. 對jdbc訪問數(shù)據(jù)庫的代碼做了封裝，大大簡化了數(shù)據(jù)訪問層繁瑣的重復性代碼。2. hibernate是一個基于jdbc的主流持久化框架，是一個優(yōu)秀的orm實現(xiàn)。他很大

23、程度的簡化dao層的編碼工作3. hibernate使用java反射機制，而不是字節(jié)碼增強程序來實現(xiàn)透明性。4. hibernate的性能非常好，因為它是個輕量級框架。映射的靈活性很出色。它支持各種關系數(shù)據(jù)庫，從一對一到多對多的各種復雜關系。2 hibernate是如何延遲加載?1. hibernate2延遲加載實現(xiàn)：a)實體對象 b)集合（collection）2. hibernate3 提供了屬性的延遲加載功能；當hibernate在查詢數(shù)據(jù)的時候，數(shù)據(jù)并沒有存在與內存中，當程序真正對數(shù)據(jù)的操作時，對象才存在與內存中，就實現(xiàn)了延遲加載，他節(jié)省了服務器的內存開銷，從而提高了服務器的性能。3h

24、ibernate中怎樣實現(xiàn)類之間的關系?(如：一對多、多對多的關系)類與類之間的關系主要體現(xiàn)在表與表之間的關系進行操作，它們都市對對象進行操作，我們程序中把所有的表與類都映射在一起，它們通過配置文件中的many-to-one、one-to-many、many-to-many、4 說下hibernate的緩存機制1. 內部緩存存在hibernate中又叫一級緩存，屬于應用事物級緩存2. 二級緩存：a) 應用及緩存b) 分布式緩存條件：數(shù)據(jù)不會被第三方修改、數(shù)據(jù)大小在可接受范圍、數(shù)據(jù)更新頻率低、同一數(shù)據(jù)被系統(tǒng)頻繁使用、非 關鍵數(shù)據(jù)c) 第三方緩存的實現(xiàn)5 hibernate的查詢方式sql、cri

25、teria,object comptositionhql：1、 屬性查詢2、 參數(shù)查詢、命名參數(shù)查詢3、 關聯(lián)查詢4、 分頁查詢5、 統(tǒng)計函數(shù)6 如何優(yōu)化hibernate？1.使用雙向一對多關聯(lián)，不使用單向一對多2.靈活使用單向一對多關聯(lián)3.不用一對一，用多對一取代4.配置對象緩存，不使用集合緩存5.一對多集合使用bag,多對多集合使用set6. 繼承類使用顯式多態(tài)7. 表字段要少，表關聯(lián)不要怕多，有二級緩存撐腰7 struts工作機制？為什么要使用struts？工作機制：struts的工作流程:在web應用啟動時就會加載初始化actionservlet,actionservlet從stru

26、ts-config.xml文件中讀取配置信息,把它們存放到各種配置對象當actionservlet接收到一個客戶請求時,將執(zhí)行如下流程.-(1)檢索和用戶請求匹配的actionmapping實例,如果不存在,就返回請求路徑無效信息;-(2)如果actionform實例不存在,就創(chuàng)建一個actionform對象,把客戶提交的表單數(shù)據(jù)保存到actionform對象中;-(3)根據(jù)配置信息決定是否需要表單驗證.如果需要驗證,就調用actionform的validate()方法;-(4)如果actionform的validate()方法返回null或返回一個不包含actionmessage的actui

27、berrors對象, 就表示表單驗證成功;-(5)actionservlet根據(jù)actionmapping所包含的映射信息決定將請求轉發(fā)給哪個action,如果相應的 action實例不存在,就先創(chuàng)建這個實例,然后調用action的execute()方法;-(6)action的execute()方法返回一個actionforward對象,actionservlet在把客戶請求轉發(fā)給 actionforward對象指向的jsp組件;-(7)actionforward對象指向jsp組件生成動態(tài)網(wǎng)頁,返回給客戶;為什么要用：jsp、servlet、javabean技術的出現(xiàn)給我們構建強大的企業(yè)應用系

28、統(tǒng)提供了可能。但用這些技術構建的系統(tǒng)非常的繁亂，所以在此之上，我們需要一個規(guī)則、一個把這些技術組織起來的規(guī)則，這就是框架，struts便應運而生?；趕truts開發(fā)的應用由3類組件構成：控制器組件、模型組件、視圖組件8 struts的validate框架是如何驗證的？在struts配置文件中配置具體的錯誤提示，再在formbean中的validate()方法具體調用。9 說下struts的設計模式mvc 模式: web應用程序啟動時就會加載并初始化actionservler。用戶提交表單時，一個配置好的actionform對象被創(chuàng)建，并被填入表單相應的數(shù)據(jù)，actionservler根據(jù)st

29、ruts-config.xml文件配置好的設置決定是否需要表單驗證，如果需要就調用actionform的 validate（）驗證后選擇將請求發(fā)送到哪個action，如果action不存在，actionservlet會先創(chuàng)建這個對象，然后調用 action的execute（）方法。execute（）從actionform對象中獲取數(shù)據(jù)，完成業(yè)務邏輯，返回一個actionforward對象，actionservlet再把客戶請求轉發(fā)給actionforward對象指定的jsp組件，actionforward對象指定的jsp生成動態(tài)的網(wǎng)頁，返回給客戶。10 spring工作機制及為什么要用?1.s

30、pring mvc請所有的請求都提交給dispatcherservlet,它會委托應用系統(tǒng)的其他模塊負責負責對請求進行真正的處理工作。2.dispatcherservlet查詢一個或多個handlermapping,找到處理請求的controller.3.dispatcherservlet請請求提交到目標controller4.controller進行業(yè)務邏輯處理后，會返回一個modelandview5.dispathcher查詢一個或多個viewresolver視圖解析器,找到modelandview對象指定的視圖對象6.視圖對象負責渲染返回給客戶端。為什么用：aop 讓開發(fā)人員可以創(chuàng)建非行

31、為性的關注點，稱為橫切關注點，并將它們插入到應用程序代碼中。使用 aop 后，公共服務 （比 如日志、持久性、事務等）就可以分解成方面并應用到域對象上，同時不會增加域對象的對象模型的復雜性。ioc 允許創(chuàng)建一個可以構造對象的應用環(huán)境，然后向這些對象傳遞它們的協(xié)作對象。正如單詞 倒置 所表明的，ioc 就像反 過來的 jndi。沒有使用一堆抽象工廠、服務定位器、單元素（singleton）和直接構造（straight construction），每一個對象都是用其協(xié)作對象構造的。因此是由容器管理協(xié)作對象（collaborator）。spring即使一個aop框架，也是一ioc容器。 spring

32、 最好的地方是它有助于您替換對象。有了 spring，只要用 javabean 屬性和配置文件加入依賴性（協(xié)作對象）。然后可以很容易地在需要時替換具有類似接口的協(xié)作對象。hibernate與ibatis的優(yōu)缺點及可行性分析1.優(yōu)點簡單：易于學習，易于使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現(xiàn)。實用：提供了數(shù)據(jù)映射功能，提供了對底層數(shù)據(jù)訪問的封裝（例如），提供了dao框架，可以使我們更容易的開發(fā)和配置我們的dal層。靈活：通過sql基本上可以實現(xiàn)我們不使用數(shù)據(jù)訪問框架可以實現(xiàn)的所有功能，或許更多。功能完整：提供了連接管理，緩存支持，線程支持，（分布式）事物管理，通過配置作關系對

33、象映射等數(shù)據(jù)訪問層需要解決的問題。提供了dao支持，并在dao框架中封裝了，hibernate和datamapper.增強系統(tǒng)的可維護性：通過提供dal層，將業(yè)務邏輯和數(shù)據(jù)訪問邏輯分離，使系統(tǒng)的設計更清晰，更易維護，更易單元測試。sql和代碼的分離，提高了可維護性。2.缺點滯后性：還沒有明確對。net2.0的支持。最新版本在2.0下編譯可以，但有些單元測試不能通過。不成熟，工程實踐較少：ibatisnet在實際項目中的使用較少。 只是理論上可行。半orm，工具支持較少：需要我們自己寫sql，并且。net下還未發(fā)現(xiàn)可以自動生成業(yè)務層類和配置文件的工具，這點和hibernate不一樣，hibern

34、ate會為我們的數(shù)據(jù)庫直接產生sql，并有一些輔助工具。因此使用ibatis比hibernate要多做一些工作。沒有最好的框架，只有最適合的框架。存在的便是合理的，它存在就說明有它存在的道理。但它未必為我們存在。所以選擇一個框架最主要的是看它對你有沒有意義，意義有多大，是不是比其他框架帶給你的好處要多。沒有絕對的優(yōu)點也沒有絕對的缺點，重要的是看在什么情況下討論。上面說了部分的ibatis的優(yōu)點和部分缺點。這些優(yōu)點從理論上證明ibatis對任何數(shù)據(jù)持久層都合適，但未必是最好的選擇。下面對上面的優(yōu)缺點分別從兩方面討論。簡單：我們都喜歡簡單，簡單意味著學習成本低，使用中出錯的可能性低。同時，簡單的東

35、西一般來說功能不夠強大。反過來，復雜的東西學習成本高，用起來不方便，并且團隊沒有很強的技術實力，一般不要使用。實用：解決了項目中需要解決的問題，這是任何實際工程中采用的框架和工具都應具有的性質，否則就不要拿到實際項目中來。靈活：靈活有兩層意思，一種是簡單易擴展，另一種是功能強大提供了很多選項。ibatis屬于前者，hibernate屬于后者。兩者各有優(yōu)缺點。 功能完整：ibatis的功能完整也是相對的，比我們自己開發(fā)的框架應該完整，但對比其他框架肯定也有一些解決不了的問題。增強系統(tǒng)的可維護性：利用ibatis可以做到sql和代碼分離，可以設計出一個清晰的數(shù)據(jù)訪問層（dal）。但項目架構是否科學

36、合理，是否以維護，關鍵不在ibatis，因為它只是一個數(shù)據(jù)層框架。但是我們也不得不清楚，要想發(fā)揮ibatis的優(yōu)勢，我們需要做一些額外工作，比如最好設計dao接口，需要將業(yè)務層實體和對實體的訪問放在不同的工程中，同時需要維護xml配置文件。滯后性：ibatis組現(xiàn)在還沒有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出現(xiàn)了問題。所以如果要使用。net2.0開發(fā)，ibatis不是一個好選擇，還需要等待。不成熟：開源的東西很難說成熟，但一般比我們自己寫的框架要成熟。由于我們可以拿到他的源代碼，所以關鍵在于我們能否駕馭它。半orm，工具支持少：這注定了ibatis不能從本質上提

37、升開發(fā)效率，我們需要自己寫sql，寫實體類，寫配置文件。但這也是它優(yōu)越的地方，它沒有為我們做的他多，所以我們就有更多的施展空間。而且它非常適合那些并不能完全控制數(shù)據(jù)庫的系統(tǒng)和需要利用數(shù)據(jù)庫本身提供的高級特性的統(tǒng)計查詢系統(tǒng)的開發(fā)。使用ibatis需要自己寫sql，由于我們的sql不可能完全符合sql標準，比起hibernate產生的sql來，可移植性差。不過由于我們更改 數(shù)據(jù)庫的可能性較小，對我們來說sql符合標準以便可以在遷移到不同服務器時代價最小并不是十分必要的。另一方面，hibernate雖然可以屏蔽很多 數(shù)據(jù)庫間的不同，但是卻很難利用某些數(shù)據(jù)庫的高級特性，比如oracle的分析統(tǒng)計函數(shù)。

38、hibernate不適合數(shù)據(jù)庫模式不規(guī)范，約束不完整，需要大量復雜查詢的系統(tǒng)，同時hibernate的學習成本較高，完全掌握hibernate也較困難，風險較大。自己寫框架未必比ibatis的好，穩(wěn)定，強大和可擴展。而且自己開發(fā)框架也需要較大的工作量。如果使用dotnet并且要選一個數(shù)據(jù)層框架，而系統(tǒng)中有相當一部分較復雜的sql，或數(shù)據(jù)庫設計不合理，臟數(shù)據(jù)多，對性能和資源要求嚴格，ibatis 是一個比較不錯的選擇。他的那些缺點并不是致命的，而且也是有一些解決方案的。尤其是，當選用了ibatis的dataaccess作為dao框架時，我們可以同時使用hibernate，和datamapper（

39、ibatisnet的核心組件），那樣將會使風險降到最低，并且整個系統(tǒng)的框架比較合理。另外，利用ibatis可以統(tǒng)一編碼風格，節(jié)約開發(fā)成本，大家不會再把精力浪費到分頁 連接池 主鍵生成等地方了，可以集中精力進行業(yè)務組件的編寫。綜上： 很多時候我們要在是自己開發(fā)框架和選用第三方框架和選用什么樣的框架問題上進行綜合考慮?？紤]的標準當然是項目的當前情況和我們希望達到目的的一個平衡。ibatis只是封裝了數(shù)據(jù)訪問層，替我們做了部分的對象關系映射。但我們的代價是必須要寫xml配置文件，相對于hibernate我們還要寫很多 sql.hibernate通過工具直接從數(shù)據(jù)庫模式生成實體類和基本的配置文件，而且

40、大部分情況下不需要我們寫sql，會較大的提升開發(fā)效率。但這些也有很多的局限性，尤其是對環(huán)境的要求較高（數(shù)據(jù)庫設計，對象設計，團隊的協(xié)作等）。個人感覺ibatis對項目比較有意義的地方在于它小巧靈活，可擴展，封裝了數(shù)據(jù)訪問層（事務，緩存，異常，日志），并提供了dao框架支持。利用ibatis我們可以做到代碼和sql的分離，只要sql能夠解決的問題，ibatis就能幫我們較容易的解決，同時也使我們的項目對某一框架的依賴性變?。ㄒ驗閕batis是非侵入性的）。這將極大的降低項目風險，減少解決復雜問題的時間，使項目的維護變得簡單。ibatis對于應用的修改，調試，擴充和維護將會變得容易自然。修改時，我

41、們主要修改的是代表模型的實體對象，xml配置文件中的sql，和/或配置文件的resultmap（很多時候是不需要的）。同時，sql和代碼分離，我們不用在代碼的stringbuffer的append方法之間尋找需要修改的sql.配置文件中的sql便利了我們的調試和對sql的評審及以后的sql重用。利用一些框架在前期一般會拖慢開發(fā)效率。因為我們需要付出學習成本，很多時候，使用框架需要寫很多配置文件，在使用不熟時開發(fā)速度較慢；同時利用框架往往使系統(tǒng)代碼量增大，比如model1和model2模型，開發(fā)效率應該還是model1快，四層的架構肯定比兩層的代碼量大。但對于中后期開發(fā)和維護將會極大的提高效率。

42、利用一些較完全的開發(fā)框架和代碼生成工具，在前期會較大的提高開發(fā)效率，但在后期常常會拖慢進度，并有可能成為以后維護的夢魘。比如torque生成實體類和其對應的sql，雖大幅提高了效率，但修改負擔較大。比較理想的開發(fā)方式是使用簡單框架結合簡單的代碼生成工具。框架提供系統(tǒng)的基礎服務，并規(guī)范開發(fā)?？蚣芤环矫嫣峁┝碎_發(fā)中某一方面的開發(fā)基礎支持，比如數(shù)據(jù)訪問層，事務，日志，公用類，異常等。另一方面，也為開發(fā)定義了模式，定義了系統(tǒng)的基本輪廓。同時，通過簡單的代碼生成工具生成部分低級的代碼。比如通過工具從數(shù)據(jù)庫模式生成實體類。這些類生成后我們可以自由修改。hibernate是十分強大，比較完善的orm框架，不

43、過這是它的優(yōu)點也是它的缺點。 j2ee系統(tǒng)是否采用hibernate3，是一個需要認真評估的問題。要想hibernate工作的好，數(shù)據(jù)庫的設計必須好。同時對于復雜的數(shù)據(jù)操作同時需要使用sql，hibernate3對于直接使用sql的支持比hibernate2要自然，這一點是可以接受的。hibernate比較復雜，功能強大而靈活，要用好hibernate確實不是很簡單，當然spring框架提供了對hibernate的封裝，使hibernate的使用變得簡單了點?？梢哉fibatis在任何系統(tǒng)里都適用，但未必是最好選擇。不過ibatis提供的思路是我們應該仔細考慮的。java中string的特性一、

44、創(chuàng)建。好了，知道string是非可變類以后，我們可以進一步了解string的構造方式了。創(chuàng)建一個stirng對象，主要就有以下兩種方式：java 代碼1.string str1 = new string(abc);2.stirng str2 = abc;雖然兩個語句都是返回一個string對象的引用，但是jvm對兩者的處理方式是不一樣的。對于第一種，jvm會馬上在heap中創(chuàng)建一個string對象，然后將該對象的引用返回給用戶。對于第二種，jvm首先會在內部維護的strings pool中通過string的 equels 方法查找是對象池中是否存放有該string對象，如果有，則返回已有的st

45、ring對象給用戶，而不會在heap中重新創(chuàng)建一個新的string對象；如果對象池中沒有該string對象，jvm則在heap中創(chuàng)建新的string對象，將其引用返回給用戶，同時將該引用添加至strings pool中。注意：使用第一種方法創(chuàng)建對象時，jvm是不會主動把該對象放到strings pool里面的，除非程序調用 string的intern方法。看下面的例子：java 代碼1.string str1 = new string(abc); /jvm 在堆上創(chuàng)建一個string對象2.3./jvm 在strings pool中找不到值為“abc”的字符串，因此4./在堆上創(chuàng)建一個stri

46、ng對象，并將該對象的引用加入至strings pool中5./此時堆上有兩個string對象6.stirng str2 = abc;7.8.if(str1 = str2)9. system.out.println(str1 = str2);10.else11. system.out.println(str1 != str2);12.13. /打印結果是 str1 != str2,因為它們是堆上兩個不同的對象14.15. string str3 = abc;16./此時，jvm發(fā)現(xiàn)strings pool中已有“abc”對象了，因為“abc”equels “abc”17./因此直接返回str2

47、指向的對象給str3，也就是說str2和str3是指向同一個對象的引用18. if(str2 = str3)19. system.out.println(str2 = str3);20. else21. system.out.println(str2 != str3);22. 23./打印結果為 str2 = str3再看下面的例子：java 代碼1.string str1 = new string(abc); /jvm 在堆上創(chuàng)建一個string對象2.3.str1 = ern();4./程序顯式將str1放到strings pool中，intern運行過程是這樣的：首先查看

48、strings pool5./有沒“abc”對象的引用，沒有，則在堆中新建一個對象，然后將新對象的引用加入至6./strings pool中。執(zhí)行完該語句后，str1原來指向的string對象已經(jīng)成為垃圾對象了，隨時會7./被gc收集。8.9./此時，jvm發(fā)現(xiàn)strings pool中已有“abc”對象了，因為“abc”equels “abc”10./因此直接返回str1指向的對象給str2，也就是說str2和str1引用著同一個對象，11./此時，堆上的有效對象只有一個。12.stirng str2 = abc;13.14.if(str1 = str2)15. system.out.pri

49、ntln(str1 = str2);16.else17. system.out.println(str1 != str2);18.19. /打印結果是 str1 = str220.為什么jvm可以這樣處理string對象呢？就是因為string的非可變性。既然所引用的對象一旦創(chuàng)建就永不更改，那么多個引用共用一個對象時互不影響。比如integer是int包裝類、float是float的包裝類等等。對這些包裝類的值操作實際上都是通過對其對應的基本類型操作而實現(xiàn)的。是不是有所感悟了？對，string就相當于是char的包裝類。包裝類的特質之一就是在對其值進行操作時會體現(xiàn)出其對應的基本類型的性質。在參

50、數(shù)傳遞時，包裝類就是如此體現(xiàn)的。所以，對于string在這種情況下的展現(xiàn)結果的解釋就自然而然得出了。同樣的，integer、float等這些包裝類和 string在這種情況下的表現(xiàn)是相同的所以如下程序輸出 1234public class test public static void changestr(string str)str=welcome;public static void main(string args) string str=1234;changestr(str);system.out.println(str);java中int和integer的區(qū)別int 是基本類型，直接

51、存數(shù)值integer是對象，用一個引用指向這個對象1.java 中的數(shù)據(jù)類型分為基本數(shù)據(jù)類型和復雜數(shù)據(jù)類型int 是前者integer 是后者（也就是一個類）2.初始化時int i =1;integer i= new integer(1);(要把integer 當做一個類看)int 是基本數(shù)據(jù)類型（面向過程留下的痕跡，不過是對java的有益補充）integer 是一個類，是int的擴展，定義了很多的轉換方法類似的還有：float float;double double;string string等舉個例子：當需要往arraylist，hashmap中放東西時，像int，double這種內建類型

52、是放不進去的，因為容器都是裝 object的，這是就需要這些內建類型的外覆類了。java中每種內建類型都有相應的外覆類。java中int和integer關系是比較微妙的。關系如下：1.int是基本的數(shù)據(jù)類型；2.integer是int的封裝類；3.int和integer都可以表示某一個數(shù)值；4.int和integer不能夠互用，因為他們兩種不同的數(shù)據(jù)類型；舉例說明arraylist al=new arraylist();int n=40;integer ni=new integer(n);al.add(n);/不可以al.add(ni);/可以華為的java面試考題 . linux怎么查看虛擬

53、內存？2.為什么java中要用final 這個機制不是和java的繼承相矛盾嗎？3.hibernate為什么要用變量綁定？有什么優(yōu)勢？4.java虛擬機怎么加載1個類的2個版本？如果能加載？怎么加載？就是一個類 生成jar包后 然后改動這個類再生成一個jar包 能同時加載嗎？這2個類嗎 ？5.struts能實現(xiàn)設計人員和開發(fā)人員負責模塊分離嗎？6.為什么要用連接池？7.tomcat5.0和6.0區(qū)別？8.uoin 和 uoin all區(qū)別？9. web service?簡單簡述下？10. 抽象類不是實體類和接口中間層嗎？為什么還有存在？不是可去掉嗎？為什么抽象類還存在？面試中常出現(xiàn)的兩個hib

54、ernate面試題及解答 1.在數(shù)據(jù)庫中條件查詢速度很慢的時候,如何優(yōu)化?1.建索引2.減少表之間的關聯(lián)3.優(yōu)化sql，盡量讓sql很快定位數(shù)據(jù)，不要讓sql做全表查詢，應該走索引,把數(shù)據(jù)量大的表排在前面4.簡化查詢字段，沒用的字段不要，已經(jīng)對返回結果的控制，盡量返回少量數(shù)據(jù)2.在hibernate中進行多表查詢,每個表中各取幾個字段,也就是說查詢出來的結果集并沒有一個實體類與之對應,如何解決這個問題?解決方案一，按照object數(shù)據(jù)取出數(shù)據(jù)，然后自己組bean解決方案二，對每個表的bean寫構造函數(shù)，比如表一要查出field1,field2兩個字段，那么有一個構造函數(shù)就是bean(type1

55、 filed1,type2 field2) ，然后在hql里面就可以直接生成這個bean了。具體怎么用請看相關文檔，我說的不是很清楚。3.session.load()和session.get()的區(qū)別session.load/get方法均可以根據(jù)指定的實體類和id從數(shù)據(jù)庫讀取記錄，并返回與之對應的實體對象。其區(qū)別在于：如果未能發(fā)現(xiàn)符合條件的記錄，get方法返回null，而load方法會拋出一個objectnotfoundexception。load方法可返回實體的代理類實例，而get方法永遠直接返回實體類。load方法可以充分利用內部緩存和二級緩存中的現(xiàn)有數(shù)據(jù)，而get方法則僅僅在內部緩存中進行數(shù)據(jù)查找，如沒有發(fā)現(xiàn)對應數(shù)據(jù)，將越過二級緩存，直接調用sql完成數(shù)據(jù)讀取。session在加載實體對象時，將經(jīng)過的過程：首先，hibernate中維持了兩級緩存。第一級緩存由session實例維護，其中保持了session當前所有關聯(lián)實體的數(shù)據(jù)，也稱為內部緩存。而第二級緩存則存在于sessionfactory層次，由當前所有由本sessionfactory構造的session實例共享。出于性能考慮，避免無謂的數(shù)據(jù)庫訪問，session在調用數(shù)據(jù)庫查詢功能之前，會先在緩存中進行查詢。首先在第一級緩存中，通過實體類型和id進