java web 開發轉載

1.分頁的解決方案，通用性，分頁時參數丟失問題，如何解決？

2.   Hibernate最佳化問題。如何最佳化資料庫訪問，使程式訪問資料庫更最佳化。

初用HIBERNATE的人也許都遇到過效能問題，實現同一功能，用HIBERNATE與用JDBC效能相差十幾倍很正常，如果不及早調整，很可能影響整個項目的進度。

　　大體上，對於HIBERNATE效能調優的主要考慮點如下:

　　* 資料庫設計調整

　　*　HQL最佳化

　　*  API的正確使用(如根據不同的業務類型選用不同的集合及查詢API)

　　* 主配置參數(日誌，查詢快取，fetch_size, batch_size等)

* 對應檔最佳化(ID建置原則，二級緩衝，消極式載入，關聯最佳化)

　　* 一級緩衝的管理

　　* 針對二級緩衝，還有許多特有的策略

　　* 事務控制策略。

　　1、 資料庫設計

　　a) 降低關聯的複雜性

　　b) 盡量不使用聯合主鍵

　　c) ID的產生機制，不同的資料庫所提供的機制並不完全一樣

　　d) 適當的冗餘資料，不過分追求高範式

　　2、 HQL最佳化

　　HQL如果拋開它同HIBERNATE本身一些緩衝機制的關聯，HQL的最佳化技巧同普通的SQL最佳化技巧一樣，可以很容易在網上找到一些經驗之談。

　　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.1文檔的“19.5. Understanding Collection performance”中有詳細的說明。

　　8、 事務控制

　　事務方面對效能有影響的主要包括:事務方式的選用，交易隔離等級以及鎖的選用

　　a) 事務方式選用:如果不涉及多個交易管理員事務的話，不需要使用JTA，只有JDBC的事務控制就可以。

　　b) 交易隔離等級:參見標準的SQL交易隔離等級

　　c) 鎖的選用:悲觀鎖(一般由具體的交易管理員實現)，對於長事務效率低，但安全。樂觀鎖(一般在應用層級實現)，如在HIBERNATE中可以定義VERSION欄位，顯然，如果有多個應用操作資料，且這些應用不是用同一種樂觀鎖機制，則樂觀鎖會失效。因此，針對不同的資料應有不同的策略，同前面許多情況一樣，很多時候我們是在效率與安全/準確性上找一個平衡點，無論如何，最佳化都不是一個純技術的問題，你應該對你的應用和業務特徵有足夠的瞭解。

　　9、 大量操作

　　即使是使用JDBC，在進行大批資料更新時，BATCH與不使用BATCH有效率上也有很大的差別。我們可以通過設定batch_size來讓其支援大量操作。

　　舉個例子，要大量刪除某表中的對象，如“delete Account”，打出來的語句，會發現HIBERNATE找出了所有ACCOUNT的ID，再進行刪除，這主要是為了維護二級緩衝，這樣效率肯定高不了，在後續的版本中增加了bulk delete/update，但這也無法解決緩衝的維護問題。也就是說，由於有了二級緩衝的維護問題，HIBERNATE的大量操作效率並不盡如人意!

3.      網站是動態，需要頻繁訪問資料庫，如何提高訪問速度，減少伺服器壓力？

提供JDBC資料庫連結池共用,大大降低資料庫壓力；

智能動態HTML，大大減少網路資料流量；

海量資料最佳化，大大提高登入和訪問速度；

使用者介面和資料緩衝，大大提高登入速度；

多層次體繫結構，支援多個應用程式伺服器並行，大大提高系統伸縮性，並發訪問使用者數目和資料安全性

4.      搜尋引擎最佳化，如何提高網站排名。最佳化有哪些具體技術措施？

   網站結構設計中面向搜尋引擎的最佳化注意事項包括：

1)連結引用的重要性

a.以量取勝：不一定加入傳統門戶網站的分類目錄才是網站推廣，來自其他網站的任何反相連結都是有用的

b. 以質取勝：被PageRank高的網站引用能更快地提高PageRank

c. 瞭解搜尋引擎的"價值觀"：不要通過Link Farm提高自身的網站排名：Google會懲罰那些主動連結到Link Farm網站以提高自身排名網站，相應網站的頁面將不會被收入到索引中。但如果你的頁面被別的Link Farm連結了也不必擔心，因為這種被動的連結是不會被懲罰的。

d. 不要吝嗇給其他網站的連結：如果一個網頁只有大量的進入連結，而缺乏匯出連結，也會被搜尋引擎認為是沒有價值的網站。

2)如何突出關鍵詞：網頁標題、主題的設計

a.Theme Engine正在逐步超過<sp>