亚洲AV综合永久无码精品天堂,麻豆狠色伊人亚洲综合网站,亚洲乱亚洲乱妇24p

2011年9月1日

ibatis分頁<一>

package com.lxy.dialect;

public abstract interface Dialect {

public boolean supportLimit();

public String getLimitString(String sql,boolean hasoffset);

public String getLimitString(String sql,int offset,int limit);

}

package com.lxy.dialect;

public class MyDialect implements Dialect {

protected static final String SQL_END_DELIMITER = ";";

public String getLimitString(String sql, boolean hasoffset) {

return new StringBuffer(sql.length() + 20).append(trim(sql)).append(

hasoffset ? "limit ?,?" : "limit ?").append(SQL_END_DELIMITER)

.toString();

}

public String getLimitString(String sql, int offset, int limit) {

sql = trim(sql);

StringBuffer sb = new StringBuffer(sql.length() + 20);

sb.append(sql);

if (offset > 0) {

sb.append("limit").append(offset).append(',').append(limit).append(

";");

} else {

sb.append("limit").append(limit).append(";");

}

return sb.toString();

}

public boolean supportLimit() {

return true;

}

private String trim(String sql) {

sql = sql.trim();

if (sql.endsWith(";")) {

sql = sql.substring(0, sql.length() - 1 - ";".length());

}

return sql;

}

posted @ 2011-09-14 19:11 crazy-李陽閱讀(209) | 評論 (0) | 編輯收藏

package com.threadpool.test;
import java.util.LinkedList;
import java.util.Queue;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.Executors;
import java.util.concurrent.RejectedExecutionException;
import java.util.concurrent.RejectedExecutionHandler;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

import org.omg.CORBA.TIMEOUT;

import com.nio.test.ReadFileThread;

public class ThreadPoolManager {

   private static ThreadPoolManager tpm = new ThreadPoolManager();

   // 線程池最小線程數
   private final static int MIN_SIZE = 4;
    // 線程池最大線程數
   private final static int MAX_SIZE = 10;
    // 線程池維護線程允許的空閑限制
   private final static int KEEP_ACTIVE_TIME = 0;
    // 線程池用的緩沖隊列大小
   private final static int WORK_QUEUE_SIZE = 10;
   // 消息緩沖隊列
   Queue queue = new LinkedList();

   final Runnable accessBuffeThread = new Runnable()
   {

       public void run() {

           if( hasMoreAcquire() ){

               String msg = ( String ) queue.poll();
               Runnable task = new AccessDBThread( msg );
               threadpool.execute( task );
           }
       }

   };
   // 無法由 ThreadPoolExecutor 執行的任務的處理程序
   final RejectedExecutionHandler handler = new RejectedExecutionHandler()
   {

       public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
           // TODO Auto-generated method stub
           System.out.println(((AccessDBThread )r).getMsg()+"消息放入隊列中重新等待執行");
           queue.offer((( AccessDBThread ) r ).getMsg() );
       }

   };

   final ThreadPoolExecutor threadpool = new ThreadPoolExecutor(MIN_SIZE, MAX_SIZE, KEEP_ACTIVE_TIME, TimeUnit.SECONDS, new ArrayBlockingQueue(WORK_QUEUE_SIZE),this.handler);

   // 調度線程池

   final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool( 1 );

   final ScheduledFuture taskHandler = scheduler.scheduleAtFixedRate(accessBuffeThread, 0, 1, TimeUnit.SECONDS);

   public static ThreadPoolManager newinstance()
   {
       return tpm;
   }

   private ThreadPoolManager (){}


   private boolean hasMoreAcquire()
   {
       return !queue.isEmpty();
   }

   public void addLogMsg(String msg)
   {
   Runnable task = new AccessDBThread(msg);
   threadpool.execute(task);
   }
}

AccessDBThread

package com.threadpool.test;

public class AccessDBThread implements Runnable{

   private String msg;
   public String getMsg() {
       return msg;
   }
   public void setMsg(String msg) {
       this.msg = msg;
   }

   public AccessDBThread(){
       super();
   }

   public AccessDBThread(String msg)
   {
       this.msg=msg;
   }
   public void run() {
       // TODO Auto-generated method stub
       System.out.println("Added the message: "+msg+" into the Database");
   }


}

測試類：
package com.threadpool.test;

public class TestDriver {

   ThreadPoolManager tpm = ThreadPoolManager.newinstance();

   public void addMsg(String msg)
   {
       tpm.addLogMsg(msg);
   }
   public static void main(String[] args) {
       for(int i=0;i<100;i++)
       {
           new TestDriver().addMsg(Integer.toString(i));
       }
   }
}

posted @ 2011-09-02 15:20 crazy-李陽閱讀(417) | 評論 (0) | 編輯收藏

線程池

為什么要用線程池？

諸如 Web 服務器、數據庫服務器、文件服務器或郵件服務器之類的許多服務器應用程序都面向處理來自某些遠程來源的大量短小的任務。請求以某種方式到達服務器，這種方式可能是通過網絡協議（例如 HTTP、FTP 或 POP）、通過 JMS 隊列或者可能通過輪詢數據庫。不管請求如何到達，服務器應用程序中經常出現的情況是：單個任務處理的時間很短而請求的數目卻是巨大的。

構建服務器應用程序的一個過于簡單的模型應該是：每當一個請求到達就創建一個新線程，然后在新線程中為請求服務。實際上，對于原型開發這種方法工作得很好，但如果試圖部署以這種方式運行的服務器應用程序，那么這種方法的嚴重不足就很明顯。每個請求對應一個線程（thread-per-request）方法的不足之一是：為每個請求創建一個新線程的開銷很大；為每個請求創建新線程的服務器在創建和銷毀線程上花費的時間和消耗的系統資源要比花在處理實際的用戶請求的時間和資源更多。

除了創建和銷毀線程的開銷之外，活動的線程也消耗系統資源。在一個 JVM 里創建太多的線程可能會導致系統由于過度消耗內存而用完內存或“切換過度”。為了防止資源不足，服務器應用程序需要一些辦法來限制任何給定時刻處理的請求數目。

線程池為線程生命周期開銷問題和資源不足問題提供了解決方案。通過對多個任務重用線程，線程創建的開銷被分攤到了多個任務上。其好處是，因為在請求到達時線程已經存在，所以無意中也消除了線程創建所帶來的延遲。這樣，就可以立即為請求服務，使應用程序響應更快。而且，通過適當地調整線程池中的線程數目，也就是當請求的數目超過某個閾值時，就強制其它任何新到的請求一直等待，直到獲得一個線程來處理為止，從而可以防止資源不足。

使用線程池的風險

雖然線程池是構建多線程應用程序的強大機制，但使用它并不是沒有風險的。用線程池構建的應用程序容易遭受任何其它多線程應用程序容易遭受的所有并發風險，諸如同步錯誤和死鎖，它還容易遭受特定于線程池的少數其它風險，諸如與池有關的死鎖、資源不足和線程泄漏。

死鎖

任何多線程應用程序都有死鎖風險。當一組進程或線程中的每一個都在等待一個只有該組中另一個進程才能引起的事件時，我們就說這組進程或線程死鎖了。死鎖的最簡單情形是：線程 A 持有對象 X 的獨占鎖，并且在等待對象 Y 的鎖，而線程 B 持有對象 Y 的獨占鎖，卻在等待對象 X 的鎖。除非有某種方法來打破對鎖的等待（Java 鎖定不支持這種方法），否則死鎖的線程將永遠等下去。

雖然任何多線程程序中都有死鎖的風險，但線程池卻引入了另一種死鎖可能，在那種情況下，所有池線程都在執行已阻塞的等待隊列中另一任務的執行結果的任務，但這一任務卻因為沒有未被占用的線程而不能運行。當線程池被用來實現涉及許多交互對象的模擬，被模擬的對象可以相互發送查詢，這些查詢接下來作為排隊的任務執行，查詢對象又同步等待著響應時，會發生這種情況。

資源不足

線程池的一個優點在于：相對于其它替代調度機制（有些我們已經討論過）而言，它們通常執行得很好。但只有恰當地調整了線程池大小時才是這樣的。線程消耗包括內存和其它系統資源在內的大量資源。除了 Thread 對象所需的內存之外，每個線程都需要兩個可能很大的執行調用堆棧。除此以外，JVM 可能會為每個 Java 線程創建一個本機線程，這些本機線程將消耗額外的系統資源。最后，雖然線程之間切換的調度開銷很小，但如果有很多線程，環境切換也可能嚴重地影響程序的性能。

如果線程池太大，那么被那些線程消耗的資源可能嚴重地影響系統性能。在線程之間進行切換將會浪費時間，而且使用超出比您實際需要的線程可能會引起資源匱乏問題，因為池線程正在消耗一些資源，而這些資源可能會被其它任務更有效地利用。除了線程自身所使用的資源以外，服務請求時所做的工作可能需要其它資源，例如 JDBC 連接、套接字或文件。這些也都是有限資源，有太多的并發請求也可能引起失效，例如不能分配 JDBC 連接。

并發錯誤

線程池和其它排隊機制依靠使用 wait() 和 notify() 方法，這兩個方法都難于使用。如果編碼不正確，那么可能丟失通知，導致線程保持空閑狀態，盡管隊列中有工作要處理。使用這些方法時，必須格外小心；即便是專家也可能在它們上面出錯。而最好使用現有的、已經知道能工作的實現，例如在下面的無須編寫您自己的池中討論的 util.concurrent 包。

線程泄漏

各種類型的線程池中一個嚴重的風險是線程泄漏，當從池中除去一個線程以執行一項任務，而在任務完成后該線程卻沒有返回池時，會發生這種情況。發生線程泄漏的一種情形出現在任務拋出一個 RuntimeException 或一個 Error 時。如果池類沒有捕捉到它們，那么線程只會退出而線程池的大小將會永久減少一個。當這種情況發生的次數足夠多時，線程池最終就為空，而且系統將停止，因為沒有可用的線程來處理任務。

有些任務可能會永遠等待某些資源或來自用戶的輸入，而這些資源又不能保證變得可用，用戶可能也已經回家了，諸如此類的任務會永久停止，而這些停止的任務也會引起和線程泄漏同樣的問題。如果某個線程被這樣一個任務永久地消耗著，那么它實際上就被從池除去了。對于這樣的任務，應該要么只給予它們自己的線程，要么只讓它們等待有限的時間。

請求過載

僅僅是請求就壓垮了服務器，這種情況是可能的。在這種情形下，我們可能不想將每個到來的請求都排隊到我們的工作隊列，因為排在隊列中等待執行的任務可能會消耗太多的系統資源并引起資源缺乏。在這種情形下決定如何做取決于您自己；在某些情況下，您可以簡單地拋棄請求，依靠更高級別的協議稍后重試請求，您也可以用一個指出服務器暫時很忙的響應來拒絕請求。

有效使用線程池的準則

只要您遵循幾條簡單的準則，線程池可以成為構建服務器應用程序的極其有效的方法：

不要對那些同步等待其它任務結果的任務排隊。這可能會導致上面所描述的那種形式的死鎖，在那種死鎖中，所有線程都被一些任務所占用，這些任務依次等待排隊任務的結果，而這些任務又無法執行，因為所有的線程都很忙。
在為時間可能很長的操作使用合用的線程時要小心。如果程序必須等待諸如 I/O 完成這樣的某個資源，那么請指定最長的等待時間，以及隨后是失效還是將任務重新排隊以便稍后執行。這樣做保證了：通過將某個線程釋放給某個可能成功完成的任務，從而將最終取得某些進展。
理解任務。要有效地調整線程池大小，您需要理解正在排隊的任務以及它們正在做什么。它們是 CPU 限制的（CPU-bound）嗎？它們是 I/O 限制的（I/O-bound）嗎？您的答案將影響您如何調整應用程序。如果您有不同的任務類，這些類有著截然不同的特征，那么為不同任務類設置多個工作隊列可能會有意義，這樣可以相應地調整每個池。

posted @ 2011-09-01 14:01 crazy-李陽閱讀(238) | 評論 (0) | 編輯收藏

ibatis分頁<一>

線程池代碼

線程池

導航

統計

常用鏈接

留言簿

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜