摘要: 分頁顯示一直是web開發中一大煩瑣的難題，傳統的網頁設計只在一個JSP或者ASP頁面中書寫所有關于數據庫操作的代碼，那樣做分頁可能簡單一點，但當把網站分層開發后，分頁就比較困難了，下面是我做Spring+Hibernate+Struts2項目時設計的分頁代碼，與大家分享交流。
閱讀全文
posted @
2012-01-17 13:56 RoyPayne 閱讀(656) |
評論 (1) |
編輯 收藏1.第一個例子：
<s:select list="{'aa','bb','cc'}" theme="simple" headerKey="00" headerValue="00"></s:select>
2.第二個例子：
<s:select list="#{1:'aa',2:'bb',3:'cc'}" label="abc" listKey="key" listValue="value" headerKey="0" headerValue="aabb">
3.第三個例子：
<%
java.util.HashMap map = new java.util.LinkedHashMap();
map.put(1,"aaa");
map.put(2,"bbb");
map.put(3,"ccc");
request.setAttribute("map",map);
request.setAttribute("aa","2");
%>
<s:select list="#request.map" label="abc" listKey="key" listValue="value"
value="#request.aa" headerKey="0" headerValue="aabb"></
s:select
>
headerKey headerValue 為設置缺省值
4.第四個例子
public class Program implements Serializable {
/** serialVersionUID */
private static final long serialVersionUID = 1L;
private int programid;
private String programName;
public int getProgramid() {
return programid;
}
public void setProgramid(int programid) {
this.programid = programid;
}
public String getProgramName() {
return programName;
}
public void setProgramName(String programName) {
this.programName = programName;
}
}
在 xxx extends extends ActionSupport {
private List<Program> programs ;
public List<Program> getPrograms() {
return programs;
}
public void setPrograms(List<Program> programs) {
this.programs = programs;
}
}
在jsp頁面
<s:select list="programs " listValue="programName " listKey="programid " name="program" id="program"
headerKey="0l" headerValue=" " value="bean.programid "
></s:select>
紅色部分為在action里面的list,黃色為<option value="xxx">value</option>對應bean里面的字段programName
綠色為<option value="xxx",對應bean里面的字段programid
紫色為設定select被選中的值,s:select 會自動在 bean選中 key對應的值
posted @
2012-01-12 15:10 RoyPayne 閱讀(248) |
評論 (0) |
編輯 收藏工作中碰到個ConcurrentModificationException。代碼如下：
List list = ...;
for(Iterator iter = list.iterator(); iter.hasNext();) {
Object obj = iter.next();
...
if(***) {
list.remove(obj);
}
}
在執行了remove方法之后，再去執行循環，iter.next()的時候，報java.util.ConcurrentModificationException(當然，如果remove的是最后一條，就不會再去執行next()操作了)
下面來看一下源碼
public interface Iterator<E> {
boolean hasNext();
E next();
void remove();
}
public interface Collection<E> extends Iterable<E> {
...
Iterator<E> iterator();
boolean add(E o);
boolean remove(Object o);
...
}
這里有兩個remove方法
接下來來看看AbstractList
public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> {
//AbstractCollection和List都繼承了Collection
protected transient int modCount = 0;
private class Itr implements Iterator<E> { //內部類Itr
int cursor = 0;
int lastRet = -1;
int expectedModCount = modCount;
public boolean hasNext() {
return cursor != size();
}
public E next() {
checkForComodification(); //特別注意這個方法
try {
E next = get(cursor);
lastRet = cursor++;
return next;
} catch(IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
}
}
public void remove() {
if (lastRet == -1)
throw new IllegalStateException();
checkForComodification();
try {
AbstractList.this.remove(lastRet); //執行remove對象的操作
if (lastRet < cursor)
cursor--;
lastRet = -1;
expectedModCount = modCount; //重新設置了expectedModCount的值，避免了ConcurrentModificationException的產生
} catch(IndexOutOfBoundsException e) {
throw new ConcurrentModificationException();
}
}
final void checkForComodification() {
if (modCount != expectedModCount) //當expectedModCount和modCount不相等時，就拋出ConcurrentModificationException
throw new ConcurrentModificationException();
}
}
}
remove(Object o)在ArrayList中實現如下：
public boolean remove(Object o) {
if (o == null) {
for (int index = 0; index < size; index++)
if (elementData[index] == null) {
fastRemove(index);
return true;
}
} else {
for (int index = 0; index < size; index++)
if (o.equals(elementData[index])) {
fastRemove(index);
return true;
}
}
return false;
}
private void fastRemove(int index) {
modCount++; //只增加了modCount
....
}
所以，產生ConcurrentModificationException的原因就是：
執行remove(Object o)方法之后，modCount和expectedModCount不相等了。然后當代碼執行到next()方法時，判斷了checkForComodification()，發現兩個數值不等，就拋出了該Exception。
要避免這個Exception，就應該使用remove()方法。
這里我們就不看add(Object o)方法了，也是同樣的原因，但沒有對應的add()方法。一般嘛，就另建一個List了
下面是網上的其他解釋，更能從本質上解釋原因：
Iterator 是工作在一個獨立的線程中，并且擁有一個 mutex 鎖。 Iterator 被創建之后會建立一個指向原來對象的單鏈索引表，當原來的對象數量發生變化時，這個索引表的內容不會同步改變，所以當索引指針往后移動的時候就找不到要迭代的對象，所以按照 fail-fast 原則 Iterator 會馬上拋出 java.util.ConcurrentModificationException 異常。
所以 Iterator 在工作的時候是不允許被迭代的對象被改變的。但你可以使用 Iterator 本身的方法 remove() 來刪除對象， Iterator.remove() 方法會在刪除當前迭代對象的同時維護索引的一致性。
posted @
2012-01-06 17:14 RoyPayne 閱讀(206) |
評論 (0) |
編輯 收藏import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
/**
本例介紹一個特殊的隊列:BlockingQueue,如果BlockQueue是空的,從BlockingQueue取東西的操作將會被阻斷進入等待狀態,直到BlockingQueue進了東西才會被喚醒.同樣,如果BlockingQueue是滿的,任何試圖往里存東西的操作也會被阻斷進入等待狀態,直到BlockingQueue里有空間才會被喚醒繼續操作.
本例再次實現11.4線程----條件Condition中介紹的籃子程序,不過這個籃子中最多能放的蘋果數不是1,可以隨意指定.當籃子滿時,生產者進入等待狀態,當籃子空時,消費者等待.
*/
/**
使用BlockingQueue的關鍵技術點如下:
1.BlockingQueue定義的常用方法如下:
1)add(anObject):把anObject加到BlockingQueue里,即如果BlockingQueue可以容納,則返回true,否則招聘異常
2)offer(anObject):表示如果可能的話,將anObject加到BlockingQueue里,即如果BlockingQueue可以容納,則返回true,否則返回false.
3)put(anObject):把anObject加到BlockingQueue里,如果BlockQueue沒有空間,則調用此方法的線程被阻斷直到BlockingQueue里面有空間再繼續.
4)poll(time):取走BlockingQueue里排在首位的對象,若不能立即取出,則可以等time參數規定的時間,取不到時返回null
5)take():取走BlockingQueue里排在首位的對象,若BlockingQueue為空,阻斷進入等待狀態直到Blocking有新的對象被加入為止
2.BlockingQueue有四個具體的實現類,根據不同需求,選擇不同的實現類
1)ArrayBlockingQueue:規定大小的BlockingQueue,其構造函數必須帶一個int參數來指明其大小.其所含的對象是以FIFO(先入先出)順序排序的.
2)LinkedBlockingQueue:大小不定的BlockingQueue,若其構造函數帶一個規定大小的參數,生成的BlockingQueue有大小限制,若不帶大小參數,所生成的BlockingQueue的大小由Integer.MAX_VALUE來決定.其所含的對象是以FIFO(先入先出)順序排序的
3)PriorityBlockingQueue:類似于LinkedBlockQueue,但其所含對象的排序不是FIFO,而是依據對象的自然排序順序或者是構造函數的Comparator決定的順序.
4)SynchronousQueue:特殊的BlockingQueue,對其的操作必須是放和取交替完成的.
3.LinkedBlockingQueue和ArrayBlockingQueue比較起來,它們背后所用的數據結構不一樣,導致LinkedBlockingQueue的數據吞吐量要大于ArrayBlockingQueue,但在線程數量很大時其性能的可預見性低于ArrayBlockingQueue.
*/
public class BlockingQueueTest {
/**定義裝蘋果的籃子*/
public static class Basket{
//籃子,能夠容納3個蘋果
BlockingQueue<String> basket = new ArrayBlockingQueue<String>(3);
//生產蘋果,放入籃子
public void produce() throws InterruptedException{
//put方法放入一個蘋果,若basket滿了,等到basket有位置
basket.put("An apple");
}
//消費蘋果,從籃子中取走
public String consume() throws InterruptedException{
//take方法取出一個蘋果,若basket為空,等到basket有蘋果為止
return basket.take();
}
}
//測試方法
public static void testBasket(){
final Basket basket = new Basket();//建立一個裝蘋果的籃子
//定義蘋果生產者
class Producer implements Runnable{
public void run(){
try{
while(true){
//生產蘋果
System.out.println("生產者準備生產蘋果: " + System.currentTimeMillis());
basket.produce();
System.out.println("生產者生產蘋果完畢: " + System.currentTimeMillis());
//休眠300ms
Thread.sleep(300);
}
}catch(InterruptedException ex){
}
}
}
//定義蘋果消費者
class Consumer implements Runnable{
public void run(){
try{
while(true){
//消費蘋果
System.out.println("消費者準備消費蘋果: " + System.currentTimeMillis());
basket.consume();
System.out.println("消費者消費蘋果完畢: " + System.currentTimeMillis());
//休眠1000ms
Thread.sleep(1000);
}
}catch(InterruptedException ex){
}
}
}
ExecutorService service = Executors.newCachedThreadPool();
Producer producer = new Producer();
Consumer consumer = new Consumer();
service.submit(producer);
service.submit(consumer);
//程序運行5s后,所有任務停止
try{
Thread.sleep(5000);
}catch(InterruptedException ex){
}
service.shutdownNow();
}
public static void main(String[] args){
BlockingQueueTest.testBasket();
}
}
posted @
2012-01-06 16:32 RoyPayne 閱讀(233) |
評論 (0) |
編輯 收藏 Java? 語言包含兩種內在的同步機制：同步塊（或方法）和 volatile 變量。這兩種機制的提出都是為了實現代碼線程的安全性。其中 Volatile 變量的同步性較差（但有時它更簡單并且開銷更低），而且其使用也更容易出錯。在這期的 Java 理論與實踐中，Brian Goetz 將介紹幾種正確使用 volatile 變量的模式，并針對其適用性限制提出一些建議。 Java 語言中的 volatile 變量可以被看作是一種 “程度較輕的 synchronized”；與 synchronized 塊相比，volatile 變量所需的編碼較少，并且運行時開銷也較少，但是它所能實現的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile 變量的模式，并強調了幾種不適合使用 volatile 變量的情形。 鎖提供了兩種主要特性：互斥（mutual exclusion）和可見性（visibility）。互斥即一次只允許一個線程持有某個特定的鎖，因此可使用該特性實現對共享數據的協調訪問協議，這樣，一次就只有一個線程能夠使用該共享數據。可見性要更加復雜一些，它必須確保釋放鎖之前對共享數據做出的更改對于隨后獲得該鎖的另一個線程是可見的 —— 如果沒有同步機制提供的這種可見性保證，線程看到的共享變量可能是修改前的值或不一致的值，這將引發許多嚴重問題。Volatile 變量
Volatile 變量具有 synchronized 的可見性特性，但是不具備原子特性。這就是說線程能夠自動發現 volatile 變量的最新值。Volatile 變量可用于提供線程安全，但是只能應用于非常有限的一組用例：多個變量之間或者某個變量的當前值與修改后值之間沒有約束。因此，單獨使用 volatile 還不足以實現計數器、互斥鎖或任何具有與多個變量相關的不變式（Invariants）的類（例如 “start <=end”）。 出于簡易性或可伸縮性的考慮，您可能傾向于使用 volatile 變量而不是鎖。當使用 volatile 變量而非鎖時，某些習慣用法（idiom）更加易于編碼和閱讀。此外，volatile 變量不會像鎖那樣造成線程阻塞，因此也很少造成可伸縮性問題。在某些情況下，如果讀操作遠遠大于寫操作，volatile 變量還可以提供優于鎖的性能優勢。正確使用 volatile 變量的條件
您只能在有限的一些情形下使用 volatile 變量替代鎖。要使 volatile 變量提供理想的線程安全，必須同時滿足下面兩個條件： ● 對變量的寫操作不依賴于當前值。 ● 該變量沒有包含在具有其他變量的不變式中。 實際上，這些條件表明，可以被寫入 volatile 變量的這些有效值獨立于任何程序的狀態，包括變量的當前狀態。 第一個條件的限制使 volatile 變量不能用作線程安全計數器。雖然增量操作（x++）看上去類似一個單獨操作，實際上它是一個由讀取－修改－寫入操作序列組成的組合操作，必須以原子方式執行，而 volatile 不能提供必須的原子特性。實現正確的操作需要使 x 的值在操作期間保持不變，而 volatile 變量無法實現這點。（然而，如果將值調整為只從單個線程寫入，那么可以忽略第一個條件。） 大多數編程情形都會與這兩個條件的其中之一沖突，使得 volatile 變量不能像 synchronized 那樣普遍適用于實現線程安全。清單 1 顯示了一個非線程安全的數值范圍類。它包含了一個不變式 —— 下界總是小于或等于上界。
清單 1. 非線程安全的數值范圍類
@NotThreadSafe
public class NumberRange {
private int lower, upper;
public int getLower() {
return lower; }
public int getUpper() {
return upper; }
public void setLower(
int value) {
if (value > upper)
throw new IllegalArgumentException(
);
lower = value;
}
public void setUpper(
int value) {
if (value < lower)
throw new IllegalArgumentException(
);
upper = value;
}
}
這種方式限制了范圍的狀態變量，因此將 lower 和 upper 字段定義為 volatile 類型不能夠充分實現類的線程安全；從而仍然需要使用同步。否則，如果湊巧兩個線程在同一時間使用不一致的值執行 setLower 和 setUpper 的話，則會使范圍處于不一致的狀態。例如，如果初始狀態是 (0, 5)，同一時間內，線程 A 調用 setLower(4) 并且線程 B 調用 setUpper(3)，顯然這兩個操作交叉存入的值是不符合條件的，那么兩個線程都會通過用于保護不變式的檢查，使得最后的范圍值是 (4, 3) —— 一個無效值。至于針對范圍的其他操作，我們需要使 setLower() 和 setUpper() 操作原子化 —— 而將字段定義為 volatile 類型是無法實現這一目的的。
性能考慮
使用 volatile 變量的主要原因是其簡易性：在某些情形下，使用 volatile 變量要比使用相應的鎖簡單得多。使用 volatile 變量次要原因是其性能：某些情況下，volatile 變量同步機制的性能要優于鎖。 很難做出準確、全面的評價，例如 “X 總是比 Y 快”，尤其是對 JVM 內在的操作而言。（例如，某些情況下 VM 也許能夠完全刪除鎖機制，這使得我們難以抽象地比較 volatile和 synchronized 的開銷。）就是說，在目前大多數的處理器架構上，volatile 讀操作開銷非常低 —— 幾乎和非 volatile 讀操作一樣。而 volatile 寫操作的開銷要比非 volatile 寫操作多很多，因為要保證可見性需要實現內存界定（Memory Fence），即便如此，volatile 的總開銷仍然要比鎖獲取低。 volatile 操作不會像鎖一樣造成阻塞，因此，在能夠安全使用 volatile 的情況下，volatile 可以提供一些優于鎖的可伸縮特性。如果讀操作的次數要遠遠超過寫操作，與鎖相比，volatile 變量通常能夠減少同步的性能開銷。正確使用 volatile 的模式
很多并發性專家事實上往往引導用戶遠離 volatile 變量，因為使用它們要比使用鎖更加容易出錯。然而，如果謹慎地遵循一些良好定義的模式，就能夠在很多場合內安全地使用 volatile 變量。要始終牢記使用 volatile 的限制 —— 只有在狀態真正獨立于程序內其他內容時才能使用 volatile —— 這條規則能夠避免將這些模式擴展到不安全的用例。 模式 #1：狀態標志 也許實現 volatile 變量的規范使用僅僅是使用一個布爾狀態標志，用于指示發生了一個重要的一次性事件，例如完成初始化或請求停機。 很多應用程序包含了一種控制結構，形式為 “在還沒有準備好停止程序時再執行一些工作”，如清單 2 所示： 清單 2. 將 volatile 變量作為狀態標志使用
volatile boolean shutdownRequested;
public void shutdown() { shutdownRequested =
true; }
public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}
很可能會從循環外部調用 shutdown() 方法 —— 即在另一個線程中 —— 因此，需要執行某種同步來確保正確實現 shutdownRequested 變量的可見性。（可能會從 JMX 偵聽程序、GUI 事件線程中的操作偵聽程序、通過 RMI 、通過一個 Web 服務等調用）。然而，使用 synchronized 塊編寫循環要比使用清單 2 所示的 volatile 狀態標志編寫麻煩很多。由于 volatile 簡化了編碼，并且狀態標志并不依賴于程序內任何其他狀態，因此此處非常適合使用 volatile。 這種類型的狀態標記的一個公共特性是：通常只有一種狀態轉換；shutdownRequested 標志從 false 轉換為 true，然后程序停止。這種模式可以擴展到來回轉換的狀態標志，但是只有在轉換周期不被察覺的情況下才能擴展（從 false 到 true，再轉換到 false）。此外，還需要某些原子狀態轉換機制，例如原子變量。 模式 #2：一次性安全發布（one-time safe publication） 缺乏同步會導致無法實現可見性，這使得確定何時寫入對象引用而不是原語值變得更加困難。在缺乏同步的情況下，可能會遇到某個對象引用的更新值（由另一個線程寫入）和該對象狀態的舊值同時存在。（這就是造成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中對象引用在沒有同步的情況下進行讀操作，產生的問題是您可能會看到一個更新的引用，但是仍然會通過該引用看到不完全構造的對象）。 實現安全發布對象的一種技術就是將對象引用定義為 volatile 類型。清單 3 展示了一個示例，其中后臺線程在啟動階段從數據庫加載一些數據。其他代碼在能夠利用這些數據時，在使用之前將檢查這些數據是否曾經發布過。 清單 3. 將 volatile 變量用于一次性安全發布
public class BackgroundFloobleLoader {
public volatile Flooble theFlooble;
public void initInBackground() {
// do lots of stuff
theFlooble =
new Flooble();
// this is the only write to theFlooble
}
}
public class SomeOtherClass {
public void doWork() {
while (
true) {
// do some stuff
// use the Flooble, but only if it is ready
if (floobleLoader.theFlooble !=
null)
doSomething(floobleLoader.theFlooble);
}
}
}
如果 theFlooble 引用不是 volatile 類型，doWork() 中的代碼在解除對 theFlooble 的引用時，將會得到一個不完全構造的 Flooble。 該模式的一個必要條件是：被發布的對象必須是線程安全的，或者是有效的不可變對象（有效不可變意味著對象的狀態在發布之后永遠不會被修改）。volatile 類型的引用可以確保對象的發布形式的可見性，但是如果對象的狀態在發布后將發生更改，那么就需要額外的同步。 模式 #3：獨立觀察（independent observation） 安全使用 volatile 的另一種簡單模式是：定期 “發布” 觀察結果供程序內部使用。例如，假設有一種環境傳感器能夠感覺環境溫度。一個后臺線程可能會每隔幾秒讀取一次該傳感器，并更新包含當前文檔的 volatile 變量。然后，其他線程可以讀取這個變量，從而隨時能夠看到最新的溫度值。 使用該模式的另一種應用程序就是收集程序的統計信息。清單 4 展示了身份驗證機制如何記憶最近一次登錄的用戶的名字。將反復使用 lastUser 引用來發布值，以供程序的其他部分使用。 清單 4. 將 volatile 變量用于多個獨立觀察結果的發布 public class UserManager {
public volatile String lastUser;
public boolean authenticate(String user, String password) {
boolean valid = passwordIsValid(user, password);
if (valid) {
User u = new User();
activeUsers.add(u);
lastUser = user;
}
return valid;
}
}
該模式是前面模式的擴展；將某個值發布以在程序內的其他地方使用，但是與一次性事件的發布不同，這是一系列獨立事件。這個模式要求被發布的值是有效不可變的 —— 即值的狀態在發布后不會更改。使用該值的代碼需要清楚該值可能隨時發生變化。 模式 #4：“volatile bean” 模式 volatile bean 模式適用于將 JavaBeans 作為“榮譽結構”使用的框架。在 volatile bean 模式中，JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨立屬性的容器。volatile bean 模式的基本原理是：很多框架為易變數據的持有者（例如 HttpSession）提供了容器，但是放入這些容器中的對象必須是線程安全的。 在 volatile bean 模式中，JavaBean 的所有數據成員都是 volatile 類型的，并且 getter 和 setter 方法必須非常普通 —— 除了獲取或設置相應的屬性外，不能包含任何邏輯。此外，對于對象引用的數據成員，引用的對象必須是有效不可變的。（這將禁止具有數組值的屬性，因為當數組引用被聲明為 volatile 時，只有引用而不是數組本身具有 volatile 語義）。對于任何 volatile 變量，不變式或約束都不能包含 JavaBean 屬性。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean： 清單 5. 遵守 volatile bean 模式的 Person 對象
@ThreadSafe
public class Person {
private volatile String firstName;
private volatile String lastName;
private volatile int age;
public String getFirstName() { return firstName; }
public String getLastName() { return lastName; }
public int getAge() { return age; }
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public void setAge(int age) {
this.age = age;
}
}
volatile 的高級模式 前面幾節介紹的模式涵蓋了大部分的基本用例，在這些模式中使用 volatile 非常有用并且簡單。這一節將介紹一種更加高級的模式，在該模式中，volatile 將提供性能或可伸縮性優勢。 volatile 應用的的高級模式非常脆弱。因此，必須對假設的條件仔細證明，并且這些模式被嚴格地封裝了起來，因為即使非常小的更改也會損壞您的代碼！同樣，使用更高級的 volatile 用例的原因是它能夠提升性能，確保在開始應用高級模式之前，真正確定需要實現這種性能獲益。需要對這些模式進行權衡，放棄可讀性或可維護性來換取可能的性能收益 —— 如果您不需要提升性能（或者不能夠通過一個嚴格的測試程序證明您需要它），那么這很可能是一次糟糕的交易，因為您很可能會得不償失，換來的東西要比放棄的東西價值更低。 模式 #5：開銷較低的讀－寫鎖策略 目前為止，您應該了解了 volatile 的功能還不足以實現計數器。因為 ++x 實際上是三種操作（讀、添加、存儲）的簡單組合，如果多個線程湊巧試圖同時對 volatile 計數器執行增量操作，那么它的更新值有可能會丟失。 然而，如果讀操作遠遠超過寫操作，您可以結合使用內部鎖和 volatile 變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計數器使用 synchronized 確保增量操作是原子的，并使用 volatile 保證當前結果的可見性。如果更新不頻繁的話，該方法可實現更好的性能，因為讀路徑的開銷僅僅涉及 volatile 讀操作，這通常要優于一個無競爭的鎖獲取的開銷。 清單 6. 結合使用 volatile 和 synchronized 實現 “開銷較低的讀－寫鎖” @ThreadSafe
public class CheesyCounter {
// Employs the cheap read-write lock trick
// All mutative operations MUST be done with the 'this' lock held
@GuardedBy("this") private volatileint value;
public int getValue() { return value; }
public synchronizedint increment() {
return value++;
}
}
之所以將這種技術稱之為 “開銷較低的讀－寫鎖” 是因為您使用了不同的同步機制進行讀寫操作。因為本例中的寫操作違反了使用 volatile 的第一個條件，因此不能使用 volatile 安全地實現計數器 —— 您必須使用鎖。然而，您可以在讀操作中使用 volatile 確保當前值的可見性，因此可以使用鎖進行所有變化的操作，使用 volatile 進行只讀操作。其中，鎖一次只允許一個線程訪問值，volatile 允許多個線程執行讀操作，因此當使用 volatile 保證讀代碼路徑時，要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要隨時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競爭的同步機制將變得非常困難。 結束語 與鎖相比，Volatile 變量是一種非常簡單但同時又非常脆弱的同步機制，它在某些情況下將提供優于鎖的性能和伸縮性。如果嚴格遵循 volatile 的使用條件 —— 即變量真正獨立于其他變量和自己以前的值 —— 在某些情況下可以使用 volatile 代替 synchronized 來簡化代碼。然而，使用 volatile 的代碼往往比使用鎖的代碼更加容易出錯。本文介紹的模式涵蓋了可以使用 volatile 代替 synchronized 的最常見的一些用例。遵循這些模式（注意使用時不要超過各自的限制）可以幫助您安全地實現大多數用例，使用 volatile 變量獲得更佳性能。
posted @
2012-01-06 10:44 RoyPayne 閱讀(299) |
評論 (1) |
編輯 收藏
摘要: JSP內置對象：我們在使用JSP進行頁面編程時可以直接使用而不需自己創建的一些Web容器已為用戶創建好的JSP內置對象。如request，session，response，out等。下面就JSP2.0給出的9個內置對象： 內置對象類型作用域requestjavax.servlet.http.HttpServletRequestrequestresponsejavax.servlet.ht...
閱讀全文
posted @
2012-01-05 16:36 RoyPayne 閱讀(18587) |
評論 (1) |
編輯 收藏一、Propagation （事務的傳播屬性）
Propagation ： key屬性確定代理應該給哪個方法增加事務行為。這樣的屬性最重要的部份是傳播行為。有以下選項可供使用：PROPAGATION_REQUIRED--支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇。
PROPAGATION_SUPPORTS--支持當前事務，如果當前沒有事務，就以非事務方式執行。
PROPAGATION_MANDATORY--支持當前事務，如果當前沒有事務，就拋出異常。
PROPAGATION_REQUIRES_NEW--新建事務，如果當前存在事務，把當前事務掛起。
PROPAGATION_NOT_SUPPORTED--以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
PROPAGATION_NEVER--以非事務方式執行，如果當前存在事務，則拋出異常。
1： PROPAGATION_REQUIRED
加入當前正要執行的事務不在另外一個事務里，那么就起一個新的事務
比如說，ServiceB.methodB的事務級別定義為PROPAGATION_REQUIRED, 那么由于執行ServiceA.methodA的時候，
ServiceA.methodA已經起了事務，這時調用ServiceB.methodB，ServiceB.methodB看到自己已經運行在ServiceA.methodA
的事務內部，就不再起新的事務。而假如ServiceA.methodA運行的時候發現自己沒有在事務中，他就會為自己分配一個事務。
這樣，在ServiceA.methodA或者在ServiceB.methodB內的任何地方出現異常，事務都會被回滾。即使ServiceB.methodB的事務已經被
提交，但是ServiceA.methodA在接下來fail要回滾，ServiceB.methodB也要回滾
2： PROPAGATION_SUPPORTS
如果當前在事務中，即以事務的形式運行，如果當前不再一個事務中，那么就以非事務的形式運行
3： PROPAGATION_MANDATORY
必須在一個事務中運行。也就是說，他只能被一個父事務調用。否則，他就要拋出異常
4： PROPAGATION_REQUIRES_NEW
這個就比較繞口了。 比如我們設計ServiceA.methodA的事務級別為PROPAGATION_REQUIRED，ServiceB.methodB的事務級別為PROPAGATION_REQUIRES_NEW，
那么當執行到ServiceB.methodB的時候，ServiceA.methodA所在的事務就會掛起，ServiceB.methodB會起一個新的事務，等待ServiceB.methodB的事務完成以后，
他才繼續執行。他與PROPAGATION_REQUIRED 的事務區別在于事務的回滾程度了。因為ServiceB.methodB是新起一個事務，那么就是存在
兩個不同的事務。如果ServiceB.methodB已經提交，那么ServiceA.methodA失敗回滾，ServiceB.methodB是不會回滾的。如果ServiceB.methodB失敗回滾，
如果他拋出的異常被ServiceA.methodA捕獲，ServiceA.methodA事務仍然可能提交。
5： PROPAGATION_NOT_SUPPORTED
當前不支持事務。比如ServiceA.methodA的事務級別是PROPAGATION_REQUIRED ，而ServiceB.methodB的事務級別是PROPAGATION_NOT_SUPPORTED ，
那么當執行到ServiceB.methodB時，ServiceA.methodA的事務掛起，而他以非事務的狀態運行完，再繼續ServiceA.methodA的事務。
6： PROPAGATION_NEVER
不能在事務中運行。假設ServiceA.methodA的事務級別是PROPAGATION_REQUIRED， 而ServiceB.methodB的事務級別是PROPAGATION_NEVER ，
那么ServiceB.methodB就要拋出異常了。
7： PROPAGATION_NESTED
理解Nested的關鍵是savepoint。他與PROPAGATION_REQUIRES_NEW的區別是，PROPAGATION_REQUIRES_NEW另起一個事務，將會與他的父事務相互獨立，
而Nested的事務和他的父事務是相依的，他的提交是要等和他的父事務一塊提交的。也就是說，如果父事務最后回滾，他也要回滾的。
而Nested事務的好處是他有一個savepoint。
*****************************************
ServiceA {
/**
* 事務屬性配置為 PROPAGATION_REQUIRED
*/
void methodA() {
try {
//savepoint
ServiceB.methodB(); //PROPAGATION_NESTED 級別
} catch (SomeException) {
// 執行其他業務, 如 ServiceC.methodC();
}
}
}
********************************************
也就是說ServiceB.methodB失敗回滾，那么ServiceA.methodA也會回滾到savepoint點上，ServiceA.methodA可以選擇另外一個分支，比如
ServiceC.methodC，繼續執行，來嘗試完成自己的事務。
但是這個事務并沒有在EJB標準中定義。
Spring事務的隔離級別
1. ISOLATION_DEFAULT： 這是一個PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別.
另外四個與JDBC的隔離級別相對應
2. ISOLATION_READ_UNCOMMITTED： 這是事務最低的隔離級別，它充許令外一個事務可以看到這個事務未提交的數據。
這種隔離級別會產生臟讀，不可重復讀和幻像讀。
3. ISOLATION_READ_COMMITTED： 保證一個事務修改的數據提交后才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據
4. ISOLATION_REPEATABLE_READ： 這種事務隔離級別可以防止臟讀，不可重復讀。但是可能出現幻像讀。
它除了保證一個事務不能讀取另一個事務未提交的數據外，還保證了避免下面的情況產生(不可重復讀)。
5. ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。
除了防止臟讀，不可重復讀外，還避免了幻像讀。
什么是臟數據，臟讀，不可重復讀，幻覺讀？
臟讀: 指當一個事務正在訪問數據，并且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，
另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據是還沒有提交的數據， 那么另外一
個事務讀到的這個數據是臟數據，依據臟數據所做的操作可能是不正確的。
不可重復讀: 指在一個事務內，多次讀同一數據。在這個事務還沒有結束時，另外一個事務也訪問該同一數據。
那么，在第一個事務中的兩次讀數據之間，由于第二個事務的修改，那么第一個事務兩次讀到的數據
可能是不一樣的。這樣就發生了在一個事務內兩次讀到的數據是不一樣的，因此稱為是不可重復讀。
幻覺讀: 指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及
到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那么，
以后就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺一樣。
posted @
2012-01-05 15:25 RoyPayne 閱讀(391) |
評論 (0) |
編輯 收藏兩者的區別有：
1、最主要是sleep方法沒有釋放鎖，而wait方法釋放了鎖，使得其他線程可以使用同步控制塊或者方法。 2、這兩個方法來自不同的類分別是Thread和Object
3、wait，notify和notifyAll只能在同步控制方法或者同步控制塊里面使用，而sleep可以在
任何地方使用
synchronized(x){
x.notify()
//或者wait()
}
4、sleep必須捕獲異常，而wait，notify和notifyAll不需要捕獲異常
posted @
2012-01-05 14:32 RoyPayne 閱讀(462) |
評論 (0) |
編輯 收藏
public class CeilAndFloor {
public static void main(String[] args) {
/*
這兩個寶貝函數的主要任務是截掉小數以后的位數.
區別是: floor總是把數字變得越來越小，而ceil總是把數字變大。
其實名字可以理解floor是地板，ceil是天花板。
*/
System.out.println("==============Math.floor()==============");
System.out.println("Math.floor(99.1) = " + Math.floor(99.1));
System.out.println("Math.floor(-99.1) = " + Math.floor(-99.1));
System.out.println("Math.floor(99.9) = " + Math.floor(99.9));
System.out.println("Math.floor(99.9) = " + Math.floor(-99.9));
System.out.println("\n\n==============Math.ceil()==============");
System.out.println("Math.ceil(99.1) = " + Math.ceil(99.1));
System.out.println("Math.ceil(-99.1) = " + Math.ceil(-99.1));
System.out.println("Math.ceil(99.9) = " + Math.ceil(99.9));
System.out.println("Math.ceil(99.9) = " + Math.ceil(-99.9));
}
}
結果
==============Math.floor()==============
Math.floor(99.1) = 99.0
Math.floor(-99.1) = -100.0
Math.floor(99.9) = 99.0
Math.floor(99.9) = -100.0
==============Math.ceil()==============
Math.ceil(99.1) = 100.0
Math.ceil(-99.1) = -99.0
Math.ceil(99.9) = 100.0
Math.ceil(99.9) = -99.0
posted @
2012-01-05 09:20 RoyPayne 閱讀(364) |
評論 (0) |
編輯 收藏 首先編寫一個MonitorInfoBean類，用來裝載監控的一些信息，包括物理內存、剩余的物理內存、已使用的物理內存、內存使用率等字段，該類的代碼如下：
package com.amigo.performance;
/**
* 監視信息的JavaBean類.
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* @version 1.0
* Creation date: 2008-4-25 - 上午10:37:00
*/
public class MonitorInfoBean {
/** 可使用內存. */
private long totalMemory;
/** 剩余內存. */
private long freeMemory;
/** 最大可使用內存. */
private long maxMemory;
/** 操作系統. */
private String osName;
/** 總的物理內存. */
private long totalMemorySize;
/** 剩余的物理內存. */
private long freePhysicalMemorySize;
/** 已使用的物理內存. */
private long usedMemory;
/** 線程總數. */
private int totalThread;
/** cpu使用率. */
private double cpuRatio;
public long getFreeMemory() {
return freeMemory;
}
public void setFreeMemory(long freeMemory) {
this.freeMemory = freeMemory;
}
public long getFreePhysicalMemorySize() {
return freePhysicalMemorySize;
}
public void setFreePhysicalMemorySize(long freePhysicalMemorySize) {
this.freePhysicalMemorySize = freePhysicalMemorySize;
}
public long getMaxMemory() {
return maxMemory;
}
public void setMaxMemory(long maxMemory) {
this.maxMemory = maxMemory;
}
public String getOsName() {
return osName;
}
public void setOsName(String osName) {
this.osName = osName;
}
public long getTotalMemory() {
return totalMemory;
}
public void setTotalMemory(long totalMemory) {
this.totalMemory = totalMemory;
}
public long getTotalMemorySize() {
return totalMemorySize;
}
public void setTotalMemorySize(long totalMemorySize) {
this.totalMemorySize = totalMemorySize;
}
public int getTotalThread() {
return totalThread;
}
public void setTotalThread(int totalThread) {
this.totalThread = totalThread;
}
public long getUsedMemory() {
return usedMemory;
}
public void setUsedMemory(long usedMemory) {
this.usedMemory = usedMemory;
}
public double getCpuRatio() {
return cpuRatio;
}
public void setCpuRatio(double cpuRatio) {
this.cpuRatio = cpuRatio;
}
}
接著編寫一個獲得當前的監控信息的接口，該類的代碼如下所示：
package com.amigo.performance;
/**
* 獲取系統信息的業務邏輯類接口.
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* @version 1.0
* Creation date: 2008-3-11 - 上午10:06:06
*/
public interface IMonitorService {
/**
* 獲得當前的監控對象.
* @return 返回構造好的監控對象
* @throws Exception
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* Creation date: 2008-4-25 - 上午10:45:08
*/
public MonitorInfoBean getMonitorInfoBean() throws Exception;
}
該類的實現類MonitorServiceImpl如下所示：
package com.amigo.performance;
import java.io.InputStreamReader;
import java.io.LineNumberReader;
import sun.management.ManagementFactory;
import com.sun.management.OperatingSystemMXBean;
/**
* 獲取系統信息的業務邏輯實現類.
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* @version 1.0 Creation date: 2008-3-11 - 上午10:06:06
*/
public class MonitorServiceImpl implements IMonitorService {
private static final int CPUTIME = 30;
private static final int PERCENT = 100;
private static final int FAULTLENGTH = 10;
/**
* 獲得當前的監控對象.
* @return 返回構造好的監控對象
* @throws Exception
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* Creation date: 2008-4-25 - 上午10:45:08
*/
public MonitorInfoBean getMonitorInfoBean() throws Exception {
int kb = 1024;
// 可使用內存
long totalMemory = Runtime.getRuntime().totalMemory() / kb;
// 剩余內存
long freeMemory = Runtime.getRuntime().freeMemory() / kb;
// 最大可使用內存
long maxMemory = Runtime.getRuntime().maxMemory() / kb;
OperatingSystemMXBean osmxb = (OperatingSystemMXBean) ManagementFactory
.getOperatingSystemMXBean();
// 操作系統
String osName = System.getProperty("os.name");
// 總的物理內存
long totalMemorySize = osmxb.getTotalPhysicalMemorySize() / kb;
// 剩余的物理內存
long freePhysicalMemorySize = osmxb.getFreePhysicalMemorySize() / kb;
// 已使用的物理內存
long usedMemory = (osmxb.getTotalPhysicalMemorySize() - osmxb
.getFreePhysicalMemorySize())
/ kb;
// 獲得線程總數
ThreadGroup parentThread;
for (parentThread = Thread.currentThread().getThreadGroup(); parentThread
.getParent() != null; parentThread = parentThread.getParent())
;
int totalThread = parentThread.activeCount();
double cpuRatio = 0;
if (osName.toLowerCase().startsWith("windows")) {
cpuRatio = this.getCpuRatioForWindows();
}
// 構造返回對象
MonitorInfoBean infoBean = new MonitorInfoBean();
infoBean.setFreeMemory(freeMemory);
infoBean.setFreePhysicalMemorySize(freePhysicalMemorySize);
infoBean.setMaxMemory(maxMemory);
infoBean.setOsName(osName);
infoBean.setTotalMemory(totalMemory);
infoBean.setTotalMemorySize(totalMemorySize);
infoBean.setTotalThread(totalThread);
infoBean.setUsedMemory(usedMemory);
infoBean.setCpuRatio(cpuRatio);
return infoBean;
}
/**
* 獲得CPU使用率.
* @return 返回cpu使用率
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* Creation date: 2008-4-25 - 下午06:05:11
*/
private double getCpuRatioForWindows() {
try {
String procCmd = System.getenv("windir")
+ "\\system32\\wbem\\wmic.exe process get Caption,CommandLine,"
+ "KernelModeTime,ReadOperationCount,ThreadCount,UserModeTime,WriteOperationCount";
// 取進程信息
long[] c0 = readCpu(Runtime.getRuntime().exec(procCmd));
Thread.sleep(CPUTIME);
long[] c1 = readCpu(Runtime.getRuntime().exec(procCmd));
if (c0 != null && c1 != null) {
long idletime = c1[0] - c0[0];
long busytime = c1[1] - c0[1];
return Double.valueOf(
PERCENT * (busytime) / (busytime + idletime))
.doubleValue();
} else {
return 0.0;
}
} catch (Exception ex) {
ex.printStackTrace();
return 0.0;
}
}
/**
* 讀取CPU信息.
* @param proc
* @return
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* Creation date: 2008-4-25 - 下午06:10:14
*/
private long[] readCpu(final Process proc) {
long[] retn = new long[2];
try {
proc.getOutputStream().close();
InputStreamReader ir = new InputStreamReader(proc.getInputStream());
LineNumberReader input = new LineNumberReader(ir);
String line = input.readLine();
if (line == null || line.length() < FAULTLENGTH) {
return null;
}
int capidx = line.indexOf("Caption");
int cmdidx = line.indexOf("CommandLine");
int rocidx = line.indexOf("ReadOperationCount");
int umtidx = line.indexOf("UserModeTime");
int kmtidx = line.indexOf("KernelModeTime");
int wocidx = line.indexOf("WriteOperationCount");
long idletime = 0;
long kneltime = 0;
long usertime = 0;
while ((line = input.readLine()) != null) {
if (line.length() < wocidx) {
continue;
}
// 字段出現順序：Caption,CommandLine,KernelModeTime,ReadOperationCount,
// ThreadCount,UserModeTime,WriteOperation
String caption = Bytes.substring(line, capidx, cmdidx - 1)
.trim();
String cmd = Bytes.substring(line, cmdidx, kmtidx - 1).trim();
if (cmd.indexOf("wmic.exe") >= 0) {
continue;
}
// log.info("line="+line);
if (caption.equals("System Idle Process")
|| caption.equals("System")) {
idletime += Long.valueOf(
Bytes.substring(line, kmtidx, rocidx - 1).trim())
.longValue();
idletime += Long.valueOf(
Bytes.substring(line, umtidx, wocidx - 1).trim())
.longValue();
continue;
}
kneltime += Long.valueOf(
Bytes.substring(line, kmtidx, rocidx - 1).trim())
.longValue();
usertime += Long.valueOf(
Bytes.substring(line, umtidx, wocidx - 1).trim())
.longValue();
}
retn[0] = idletime;
retn[1] = kneltime + usertime;
return retn;
} catch (Exception ex) {
ex.printStackTrace();
} finally {
try {
proc.getInputStream().close();
} catch (Exception e) {
e.printStackTrace();
}
}
return null;
}
/**
* 測試方法.
* @param args
* @throws Exception
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* Creation date: 2008-4-30 - 下午04:47:29
*/
public static void main(String[] args) throws Exception {
IMonitorService service = new MonitorServiceImpl();
MonitorInfoBean monitorInfo = service.getMonitorInfoBean();
System.out.println("cpu占有率=" + monitorInfo.getCpuRatio());
System.out.println("可使用內存=" + monitorInfo.getTotalMemory());
System.out.println("剩余內存=" + monitorInfo.getFreeMemory());
System.out.println("最大可使用內存=" + monitorInfo.getMaxMemory());
System.out.println("操作系統=" + monitorInfo.getOsName());
System.out.println("總的物理內存=" + monitorInfo.getTotalMemorySize() + "kb");
System.out.println("剩余的物理內存=" + monitorInfo.getFreeMemory() + "kb");
System.out.println("已使用的物理內存=" + monitorInfo.getUsedMemory() + "kb");
System.out.println("線程總數=" + monitorInfo.getTotalThread() + "kb");
}
}
該實現類中需要用到一個自己編寫byte的工具類，該類的代碼如下所示：
package com.amigo.performance;
/**
* byte操作類.
* @author <a href="mailto:xiexingxing1121@126.com">AmigoXie</a>
* @version 1.0
* Creation date: 2008-4-30 - 下午04:57:23
*/
public class Bytes {
/**
* 由于String.subString對漢字處理存在問題（把一個漢字視為一個字節)，因此在
* 包含漢字的字符串時存在隱患，現調整如下：
* @param src 要截取的字符串
* @param start_idx 開始坐標（包括該坐標)
* @param end_idx 截止坐標（包括該坐標）
* @return
*/
public static String substring(String src, int start_idx, int end_idx){
byte[] b = src.getBytes();
String tgt = "";
for(int i=start_idx; i<=end_idx; i++){
tgt +=(char)b[i];
}
return tgt;
}
}
運行下MonitorBeanImpl類，讀者將會看到當前的內存、cpu利用率等信息。
posted @
2012-01-04 14:54 RoyPayne 閱讀(1992) |
評論 (1) |
編輯 收藏