呃. 停更4年了..

要不要寫的這么透徹. 強(qiáng)~

可以強(qiáng)制加載后 close session.
--------
此外直接用HibernateTemplate.getSessionFactory.getCurrentSession
應(yīng)該是可以托管給spring管理的.

貌似博文無(wú)法設(shè)置為僅自己可見(jiàn)?

仔細(xì)看了下你貼出的系統(tǒng)狀態(tài)結(jié)果，發(fā)現(xiàn)你的并發(fā)并不大，只是操作比較頻繁罷啦
看不到具體的實(shí)際環(huán)境情況，你試下按如下方法優(yōu)化下吧：


稍適當(dāng)增大一點(diǎn)query_cache_size；

若你的這臺(tái)服務(wù)器是專給msyql用的，不會(huì)跑其他業(yè)務(wù)，那修改如下參數(shù)：
innodb_flush_log_at_trx_commit=0 (若你允許存在丟失最近部分事務(wù)的前提下）
innodb_log_buffer_size=8M
innodb_buffer_pool_size=2560M
innodb_log_file_size=512M

適當(dāng)系統(tǒng)空閑時(shí)，對(duì)一些系統(tǒng)關(guān)鍵的大表執(zhí)行：
analyze table tb_name;
optimize table tb_name；

若問(wèn)題還沒(méi)得到解決：
則設(shè)置log_slow_queries、long_query_time啟動(dòng)“慢查詢?nèi)罩尽弊ト?wèn)題語(yǔ)句

用explain分析問(wèn)題語(yǔ)句，確定索引是否正常利用上。

-----------------------------------------------
通過(guò)上面的一系列還得不到解決：
那檢查系統(tǒng)的可能存在瓶頸的業(yè)務(wù)處理邏輯是否還存在優(yōu)化的余地；
考慮升級(jí)硬件（更快的硬盤、合理的raid方式、更快的cpu）；
考慮系統(tǒng)架構(gòu)的變更；

大概就先寫這么多吧。

HibernateUtil工具類中一般都有寫closeSession的方法.
將線程對(duì)應(yīng)的變量ThreadLocal中的session置為null.
這樣歸還線程池后又是干凈的了.

如何在Java中應(yīng)用final類 :
1 什么是final類
API中的某些類，如String，以及Math等，就是final類的典型例子。雖然在Java編程中并不經(jīng)常使用final類和final方法，但它們有著與眾不同的特點(diǎn)，即final類不能被繼承，不能被覆蓋，以及final類在執(zhí)行速度方面比一般類快。下面對(duì)final類和final方法的概念和編程技術(shù)分別加以討論，最后解釋為什么final類可以提高執(zhí)行速度。
2 不能繼承final類
有時(shí)在程序需要對(duì)繼承加以限制。例如某些處理特殊運(yùn)算和操作的類，為了安全理由，不允許被其他類所繼承。final類沒(méi)有子類，即它處于繼承鏈的尾部，或者除了自動(dòng)繼承Object之外，它們是獨(dú)立存在的支持類，例如執(zhí)行密碼管理的類，處理數(shù)據(jù)庫(kù)信息的管理類等等。
使用final類的另外一個(gè)理由是執(zhí)行速度。由于它的方法不能夠被覆蓋，所以其地址引用和裝載在編譯期間完成，而不是在運(yùn)行期間由JVM進(jìn)行復(fù)雜的裝載，因而簡(jiǎn)單和有效。所以如果沒(méi)有必要，或者不存在有繼承的可能性時(shí)，盡量使用final類。當(dāng)然，在API類庫(kù)中不多使用final類是因?yàn)樗鼈兪菢?biāo)準(zhǔn)程序，希望在實(shí)際軟件開(kāi)發(fā)中得以廣泛使用。而具體的應(yīng)用軟件開(kāi)發(fā)則不同于標(biāo)準(zhǔn)庫(kù)程序開(kāi)發(fā)。
注意final數(shù)據(jù)和final類的不同。final數(shù)據(jù)指常量，即其值一旦初始化，就不能改變。而final類則指不能被其他類所繼承的類。
3 定義final類
在類名前加以關(guān)鍵字final，這個(gè)類就被定義為final類，如：

public final class SomeClass {
...
}

或者，

public final class SomeClass extends SuperClass {
...
}

public final class SomeClass {<br/> ...<br/>}<br/> <br/>或者，<br/> <br/>public final class SomeClass extends SuperClass {<br/> ...<br/>}

當(dāng)一個(gè)類被定義為final時(shí)，它的所有方法都自動(dòng)成為final方法，但不影響對(duì)變量的定義。
4 不能覆蓋final方法
也可以在超類中定義某個(gè)方法為final方法。雖然這個(gè)類可以被繼承，但子類不能夠覆蓋final方法。API類中的許多方法，如print()和 println()，以及Math類中的所有方法都定義為final方法。在具體應(yīng)用軟件開(kāi)發(fā)中，一些執(zhí)行特殊性運(yùn)算和操作的方法，可以定義為final 方法。在方法的返回類型前加入關(guān)鍵字final，則定義該方法為final，如：

public final String printVersion() { //定義final方法
return version;
}

public final String printVersion() { //定義final方法<br/> return version;<br/>}
5 final參數(shù)
final參數(shù)的含義如同final變量一樣，是常數(shù)參數(shù)，即當(dāng)方法接受了這個(gè)參數(shù)后，其值不能改變。如下代碼中定義方法的參數(shù)為final：

public void setVerison(final String version) { //定義常量參數(shù)
this.version = version;
}

在這個(gè)方法中使用如下語(yǔ)句產(chǎn)生語(yǔ)法錯(cuò)誤：

version = "other version…"; //非法操作

public void setVerison(final String version) { //定義常量參數(shù)<br/> this.version = version;<br/>}<br/> <br/> 在這個(gè)方法中使用如下語(yǔ)句產(chǎn)生語(yǔ)法錯(cuò)誤：<br/> <br/>version = "other version…"; //非法操作
6 提高執(zhí)行速度
final類可以提高執(zhí)行速度主要因?yàn)槿缦略颍?
l 不涉及繼承和覆蓋。
l 其地址引用和裝載在編譯時(shí)完成。
l 在運(yùn)行時(shí)不要求JVM執(zhí)行因覆蓋而產(chǎn)生的動(dòng)態(tài)地址引用而花費(fèi)時(shí)間和空間。
l 與繼承鏈上的一般對(duì)象相比，垃圾回收器在收回final對(duì)象所占據(jù)的地址空間時(shí)也相對(duì)簡(jiǎn)單快捷。
但在某些情況下使用final方法并不能取得提高執(zhí)行速度的結(jié)果。因?yàn)椴⒉皇撬衒inal方法其地址的裝載和引用在編譯時(shí)間完成。
假設(shè)類C繼承了B，B繼承了A，在類A中有final方法。對(duì)類C來(lái)講，調(diào)用A的final方法的確是inline編譯，即裝載在編譯時(shí)間完成；但對(duì)A和B 來(lái)講，可能沒(méi)有調(diào)用final方法。而在執(zhí)行期間，JVM動(dòng)態(tài)裝載的方法有可能并不是C所調(diào)用的final方法。這種情況下，則不能夠取得提高執(zhí)行速度的結(jié)果。當(dāng)然，如果final方法在編譯時(shí)間裝載到JVM，而且沒(méi)有在執(zhí)行期間覆蓋的，可以取得inline效益，提高執(zhí)行速度。
作者建議是：不能僅僅因?yàn)榭紤]追求提高執(zhí)行速度而使用final類。在程序設(shè)計(jì)和代碼編寫時(shí)，應(yīng)首先考慮這個(gè)類所執(zhí)行的任務(wù)和安全因素，是否允許有子類。在這個(gè)前提下，盡量提高代碼的重復(fù)應(yīng)用性是面向?qū)ο笤O(shè)計(jì)和編程的宗旨。然后考慮是否使用final類和final方法。
投票成功,感謝您的投票

蠻好的

不如做別的

感觸良多.

..說(shuō)了不如不說(shuō).

很可惜這一段寫的有點(diǎn)亂了

COOL~

動(dòng)手 動(dòng)腦 你會(huì)成為高手

為蝦米看不了代碼?

好好讀書(shū),不讀書(shū),讓你以后去做程序員!
----這是最近我看到最心酸的話.

和之前javase寫的那個(gè)動(dòng)態(tài)代理其實(shí)差不多.
一樣的啦~!
回頭看這個(gè)就很好理解了.
誒
java的東西一套一套的.
發(fā)現(xiàn)越來(lái)越多思維的局限了...

代碼參見(jiàn)項(xiàng)目:dynamic-proxy

看了那么多網(wǎng)絡(luò)上的解釋.
還是感覺(jué)尚學(xué)堂的解釋最容易懂.

動(dòng)態(tài)代理 沒(méi)接觸過(guò).看起來(lái)有點(diǎn)puzzle
..多看幾次吧..

client的寫法
把實(shí)現(xiàn)UserManagerImpl的UserManager類的實(shí)例丟到代理中.
然后再調(diào)用代理中的方法.
好了..保存了實(shí)現(xiàn)類的貞操了.
T_T... 給我?guī)讉€(gè)不用代理產(chǎn)生悲劇的歷史小故事吧...
否則實(shí)在很想開(kāi)罵使用代理的麻煩.

struts2和webwork的攔截器好像有點(diǎn)不一樣
如你知道.麻煩介紹一些.THANKS

" WebWork還有一種很方便的不需要配置的別名語(yǔ)法，支持形為name!method.action的映射。如上面的例子中，users!edit.action就會(huì)被映射到edit()方法中。"
這句有點(diǎn)不太懂.麻煩解釋下~
wait.

寫的很好啊.
看了幾篇.你這篇寫的淺顯易懂.

果然是很簡(jiǎn)單

寫的很好~

@一竿殘照.金棣 @ blogJava.net
說(shuō)的不錯(cuò)..

寫的很好 找回了記憶~
謝謝