1. java線程的幾個概念和方法
新建狀態：用new語句創建的線程對象處於新建狀態，此時它和其它的java對象一樣，僅僅在堆中被分配了內存 就緒狀態：當一個線程創建了以後，其他的線程調用了它的start()方法，該線程就進入了就緒狀態。處於這個狀態的線程位於可運行池中，等待獲得CPU的使用權
運行狀態：處於這個狀態的線程佔用CPU,執行程序的代碼
阻塞狀態：當線程處於阻塞狀態時，java虛擬機不會給線程分配CPU，直到線程重新進入就緒狀態，它才有機會轉到運行狀態。
阻塞狀態分為三種情況：
1、 位於對象等待池中的阻塞狀態：當線程運行時，如果執行了某個對象的wait()方法，java虛擬機就回把線程放到這個對象的等待池中
2、 位於對象鎖中的阻塞狀態，當線程處於運行狀態時，試圖獲得某個對象的同步鎖時，如果該對象的同步鎖已經被其他的線程佔用，JVM就會把這個線程放到這個對象的瑣池中。
3、 其它的阻塞狀態：當前線程執行了sleep()方法，或者調用了其它線程的join()方法，或者發出了I/O請求時，就會進入這個狀態中。
2. java的經典書籍有哪些呀
一、Java編程入門類
對於沒有Java編程經驗的程序員要入門，隨便讀什麼入門書籍都一樣，這個階段需要你快速的掌握Java基礎語法和基本用法，宗旨就是「囫圇吞棗不求甚解」，先對Java熟悉起來再說。用很短的時間快速過一遍Java語法，連懵帶猜多寫寫代碼，要「知其然」。
1、《Java編程思想》
在有了一定的Java編程經驗之後，你需要「知其所以然」了。這個時候《Java編程思想》是一本讓你知其所以然的好書，它對於基本的面向對象知識有比較清楚的交待，對Java基本語法，基本類庫有比較清楚的講解，可以幫你打一個良好的Java編程基礎。這本書的缺點是實在太厚，也比較羅嗦，不適合現代人快節奏學習，因此看這本書要懂得取捨，不是每章每節都值得一看的，挑重點的深入看就可以了。
2、《Agile Java》中文版
這本書是出版社送給我的，我一拿到就束之高閣，放在書櫃一頁都沒有翻過，但是前兩天整理書櫃的時候，拿出來一翻，竟然發現這絕對是一本好書！這本書一大特點是以單元測試和TDD來貫穿全書的，在教你Java各種重要的基礎知識的過程中，潛移默化的影響你的編程思維走向敏捷，走向TDD。另外這本書成書很新，以JDK5.0的語法為基礎講解，要學習JDK5.0的新語法也不錯。還有這本書對於內容取捨也非常得當，Java語言畢竟類庫龐大，可以講的內容太多，這本書選擇的內容以及內容的多寡都很得當，可以讓你以最少的時間掌握Java最重要的知識，順便培養出來優秀的編程思路，真是一本不可多得的好書。 雖然作者自己把這本書定位在入門級別，但我不確定這本書用來入門是不是稍微深了點，我自己也准備有空的時候翻翻這本書，學習學習。
二、Java編程進階類
打下一個良好的Java基礎，還需要更多的實踐經驗積累，我想沒有什麼捷徑。有兩本書值得你在編程生涯的這個階段閱讀，培養良好的編程習慣，提高你的代碼質量。
1、《重構 改善既有代碼的設計》
這本書名氣很大，不用多介紹，可以在閑暇的時候多翻翻，多和自己的實踐相互印證。這本書對你產生影響是潛移默化的。
2、《測試驅動開發 by Example》
本書最大特點是很薄，看起來沒有什麼負擔。你可以找一個周末的下午，一邊看，一邊照做，一個下午就把書看完，這本書的所有例子跑完了。這本書的作用是通過實戰讓你培養TDD的思路。
三、Java架構師之路
到這個階段，你應該已經非常嫻熟的運用Java編程，而且有了一個良好的編程思路和習慣了，但是你可能還缺乏對應用軟體整體架構的把握，現在就是你邁向架構師的第一步。
1、《Expert One-on-One J2EE Design and Development》
這本書是Rod Johnson的成名著作，非常經典，從這本書中的代碼誕生了springframework。但是好像這本書沒有中譯本。
2、《Expert One-on-One J2EE Development without EJB》
這本書由gigix組織翻譯，多位業界專家參與，雖然署名譯者是JavaEye，其實JavaEye出力不多，實在是忝居譯者之名。
以上兩本書都是Rod Johnson的經典名著，Java架構師的必讀書籍。在我所推薦的這些書籍當中，是我看過的最仔細，最認真的書，我當時讀這本書幾乎是廢寢忘食的一氣讀完的，有小時候挑燈夜讀金庸武俠小說的勁頭，書中所講內容和自己的經驗知識一一印證，又被無比精闢的總結出來，讀完這本書以後，我有種被打通經脈，功力爆增的感覺。
但是後來我看過一些其他人的評價，似乎閱讀體驗並沒有我那麼high，也許是因為每個人的知識積累和經驗不同導致的。我那個時候剛好是經驗知識積累已經足夠豐富，但是還沒有系統的整理成型，讓這本書一梳理，立刻形成完整的知識體系了。
3、《企業應用架構模式》
Martin的又一本名著，但這本書我只是泛泛的看了一遍，並沒有仔細看。這本書似乎更適合做框架的人去看，例如如果你打算自己寫一個ORM的話，這本書是一定要看的。但是做應用的人，不看貌似也無所謂，但是如果有空，我還是推薦認真看看，會讓你知道框架為什麼要這樣設計，這樣你的層次可以晉升到框架設計者的角度去思考問題。Martin的書我向來都是推崇，但是從來都沒有像Rod Johnson的書那樣非常認真去看。
4、《敏捷軟體開發 原則、模式與實踐》
Uncle Bob的名著，敏捷的經典名著，這本書比較特別，與其說是講軟體開發過程的書，不如說講軟體架構的書，本書用了很大篇幅講各種面向對象軟體開發的各種模式，個人以為看了這本書，就不必看GoF的《設計模式》了。
四、軟體開發過程
了解軟體開發過程不單純是提高程序員個人的良好編程習慣，也是增強團隊協作的基礎。
1、《UML精粹》
UML其實和軟體開發過程沒有什麼必然聯系，卻是軟體團隊協作溝通，撰寫軟體文檔需要的工具。但是UML真正實用的圖不多，看看這本書已經足夠了，完全沒有必要去啃《UML用戶指南》之類的東西。要提醒大家的是，這本書的中譯本翻譯的非常之爛，建議有條件的看英文原版。
2、《解析極限編程 擁抱變化》XP
這是Kent Beck名著的第二版，中英文對照。沒什麼好說的，必讀書籍。
3、《統一軟體開發過程》UP
其實UP和敏捷並不一定沖突，UP也非常強調迭代，測試，但是UP強調的文檔和過程驅動卻是敏捷所不取的。不管怎麼說，UP值得你去讀，畢竟在中國真正接受敏捷的企業很少，你還是需要用UP來武裝一下自己的，哪怕是披著UP的XP。
4、《敏捷建模》AM
Scott Ambler的名著，這本書非常的progmatic，告訴你怎麼既敏捷又UP，把敏捷和UP統一起來了，又提出了很多progmatic的建議和做法。你可以把《解析極限編程 擁抱變化》、《統一軟體開發過程》和《敏捷建模》這三本書放在一起讀，看XP和UP的不同點，再看AM是怎麼統一XP和UP的，把這三種理論融為一爐，形成自己的理論體系，那麼你也可以去寫書了。
五、軟體項目管理
如果你突然被領導提拔為項目經理，而你完全沒有項目管理經驗，你肯定會心裡沒底；如果你覺得自己管理項目不善，很想改善你的項目管理能力，那麼去考PMP肯定是遠水不解近渴的。
1、《快速軟體開發》
這也是一本名著。可以這樣說，有本書在手，你就有了一個項目管理的高級參謀給你出謀劃策，再也不必擔心自己不能勝任的問題了。這本書不是講管理的理論的，在實際的項目管理中，講這些理論是不解決問題的，這本書有點類似於「軟體項目點子大全」之類的東西，列舉了種種軟體項目當中面臨的各種問題，以及應該如何解決問題的點子，你只需要稍加變通，找方抓葯就行了。
六、總結
在這份推薦閱讀書籍的名單中，我沒有列舉流行的軟體框架類學習書籍，例如Struts，Hibernate，Spring之類，也沒有列舉AJAX方面的書籍。是因為這類書籍容易過時，而上述的大半書籍的生命周期都足夠長，值得你去購買和收藏。
希望對您有所幫助！~
3. java線程
樓主要先明確一點，無線循環有兩種：一種是永遠停不下來的，CPU佔用率99%；而另一種是停在某一行，在需要的時候再運行，CPU會被正常使用的。
情況1，永遠停不下來的，99%的CPU佔用：
理論上講，因為CPU被占滿了，那麼第二個Thread就不能執行了，而且其他的Process也無法正常工作了；但其實第二個Thread可以運行，因為當今Windows系統的功能很完善了，即使無限循環，Windows也能勉強應付。但這個其實就是「死機的Bug」，例如：
while(true){
System.out.println("Hang already!");
}
情況2，停在某一行，CPU正常用：
那麼一切將正常，第二個Thread可執行。例如：
private void listen(int port) throws IOException {
ServerSocket serverSocket = null;
try {
System.out.println("Server is listening...");
serverSocket = new ServerSocket(port);//創建伺服器所需插槽
} catch (IOException e) {
System.out.println("Could not listen on port: " + port + ".");
System.exit(-1);
}
while (true) {
Socket s = serverSocket.accept();//接受客戶的TCP連接
System.out.println("Connection from " + s);
new ChatServerThread(s).start();
}
serverSocket.close();
}
這個Method表面上看有 while (true) {}，彷彿是無限次循環，但其實不是。這其實是一個Java寫的TCP伺服器程序。如果沒有TCP用戶連接的情況下，那個while循環就會停在「Socket s = serverSocket.accept();」這一行；如果有TCP用戶連接了這個Java伺服器，那麼這一行才會運行，「ChatServerThread(s).start();」這一行會為這個用戶建立一個Thread，並且while-loop將完成循環一次。
這個是我大學學習期間，用Java寫的即時通訊軟體（模仿MSN），中伺服器連接那一段。我這個程序用的是Java Network和Java Concurrency（Multi-Threading多線程,Multi-Processing多進程）。你如果要我可以E-MAIL你。
4. java 線程
D
D是設置線程對象的優先順序，不能直接引起線程停止。
B wait方法肯定是停止的
C read方法是阻塞式的，線程要等待。
修改：
選D有誤。——sorry,wencst說的很多好。
線程的調度是搶先式的，而不是分時間片式的。具有比當前運行線程高優先順序的線程可以使當前線程停止運行而進入就緒狀態
5. Java線程
進程是程序在處理機中的一次運行。一個進程既包括其所要執行的指令，也包括了執行指令所需的系統資源，不同進程所佔用的系統資源相對獨立。所以進程是重量級的任務，它們之間的通信和轉換都需要操作系統付出較大的開銷。
線程是進程中的一個實體，是被系統獨立調度和分派的基本單位。線程自己基本上不擁有系統資源，但它可以與同屬一個進程的其他線程共享進程所擁有的全部資源。所以線程是輕量級的任務，它們之間的通信和轉換只需要較小的系統開銷。
Java支持多線程編程，因此用Java編寫的應用程序可以同時執行多個任務。Java的多線程機制使用起來非常方便，用戶只需關注程序細節的實現，而不用擔心後台的多任務系統。
Java語言里，線程表現為線程類。Thread線程類封裝了所有需要的線程操作控制。在設計程序時，必須很清晰地區分開線程對象和運行線程，可以將線程對象看作是運行線程的控制面板。在線程對象里有很多方法來控制一個線程是否運行，睡眠，掛起或停止。線程類是控制線程行為的唯一的手段。一旦一個Java程序啟動後，就已經有一個線程在運行。可通過調用Thread.currentThread方法來查看當前運行的是哪一個線程。
class ThreadTest{
public static void main(String args[]){
Thread t = Thread.currentThread();
t.setName("單線程"); //對線程取名為"單線程"
t.setPriority(8);
//設置線程優先順序為8，最高為10，最低為1，默認為5
System.out.println("The running thread: " + t);
// 顯示線程信息
try{
for(int i=0;i<3;i++){
System.out.println("Sleep time " + i);
Thread.sleep(100); // 睡眠100毫秒
}
}catch(InterruptedException e){// 捕獲異常
System.out.println("thread has wrong");
}
}
}
多線程的實現方法
繼承Thread類
可通過繼承Thread類並重寫其中的run()方法來定義線程體以實現線程的具體行為，然後創建該子類的對象以創建線程。
在繼承Thread類的子類ThreadSubclassName中重寫run()方法來定義線程體的一般格式為:
public class ThreadSubclassName extends Thread{
public ThreadSubclassName(){
..... // 編寫子類的構造方法，可預設
}
public void run(){
..... // 編寫自己的線程代碼
}
}
用定義的線程子類ThreadSubclassName創建線程對象的一般格式為:
ThreadSubclassName ThreadObject =
new ThreadSubclassName();
然後，就可啟動該線程對象表示的線程：
ThreadObject.start(); //啟動線程
應用繼承類Thread的方法實現多線程的程序。本程序創建了三個單獨的線程，它們分別列印自己的「Hello World!」。
class ThreadDemo extends Thread{
private String whoami;
private int delay;
public ThreadDemo(String s,int d){
whoami=s;
delay=d;
}
public void run(){
try{
sleep(delay);
}catch(InterruptedException e){ }
System.out.println("Hello World!" + whoami
+ " " + delay);
}
}
public class MultiThread{
public static void main(String args[]){
ThreadDemo t1,t2,t3;
t1 = new ThreadDemo("Thread1",
(int)(Math.random()*2000));
t2 = new ThreadDemo("Thread2",
(int)(Math.random()*2000));
t3 = new ThreadDemo("Thread3",
(int)(Math.random()*2000));
t1.start();
t2.start();
t3.start();
}
}
實現Runnable介面
編寫多線程程序的另一種的方法是實現Runnable介面。在一個類中實現Runnable介面(以後稱實現Runnable介面的類為Runnable類),並在該類中定義run()方法，然後用帶有Runnable參數的Thread類構造方法創建線程。
創建線程對象可用下面的兩個步驟來完成:
(1)生成Runnable類ClassName的對象
ClassName RunnableObject = new ClassName();
(2)用帶有Runnable參數的Thread類構造方法創建線程對象。新創建的線程的指針將指向Runnable類的實例。用該Runnable類的實例為線程提供 run()方法---線程體。
Thread ThreadObject = new Thread(RunnableObject);
然後，就可啟動線程對象ThreadObject表示的線程：
ThreadObject.start();
在Thread類中帶有Runnable介面的構造方法有:
public Thread(Runnable target);
public Thread(Runnable target, String name);
public Thread(String name);
public Thread(ThreadGroup group，Runnable target);
public Thread(ThreadGroup group，Runnable target，
String name);
其中，參數Runnable target表示該線程執行時運行target的run()方法，String name以指定名字構造線程，ThreadGroup group表示創建線程組。
用Runnable介面實現的多線程。
class TwoThread implements Runnable{
TwoThread(){
Thread t1 = Thread.currentThread();
t1.setName("第一主線程");
System.out.println("正在運行的線程: " + t1);
Thread t2 = new Thread(this,"第二線程");
System.out.println("創建第二線程");
t2.start();
try{
System.out.println("第一線程休眠");
Thread.sleep(3000);
}catch(InterruptedException e){
System.out.println("第一線程有錯");
}
System.out.println("第一線程退出");
}
public void run(){
try{
for(int i = 0;i < 5;i++){
System.out.println(「第二線程的休眠時間：」
+ i);
Thread.sleep(1000);
}
}catch(InterruptedException e){
System.out.println("線程有錯");
}
System.out.println("第二線程退出");
}
public static void main(String args[]){
new TwoThread();
}
}
程序運行結果如下：
正在運行的線程: Thread[第一主線程,5,main
創建第二線程
第一線程休眠
第二線程的休眠時間：0
第二線程的休眠時間：1
第二線程的休眠時間：2
第一線程退出
第二線程的休眠時間：3
第二線程的休眠時間：4
第二線程退出
滿意請採納。
6. JAVA 線程
這是javaeye上非常經典的關於線程的帖子，寫的非常通俗易懂的，適合任何讀計算機的同學.
線程同步
我們可以在計算機上運行各種計算機軟體程序。每一個運行的程序可能包括多個獨立運行的線程（Thread）。
線程（Thread）是一份獨立運行的程序，有自己專用的運行棧。線程有可能和其他線程共享一些資源，比如，內存，文件，資料庫等。
當多個線程同時讀寫同一份共享資源的時候，可能會引起沖突。這時候，我們需要引入線程「同步」機制，即各位線程之間要有個先來後到，不能一窩蜂擠上去搶作一團。
同步這個詞是從英文synchronize（使同時發生）翻譯過來的。我也不明白為什麼要用這個很容易引起誤解的詞。既然大家都這么用，咱們也就只好這么將就。
線程同步的真實意思和字面意思恰好相反。線程同步的真實意思，其實是「排隊」：幾個線程之間要排隊，一個一個對共享資源進行操作，而不是同時進行操作。
因此，關於線程同步，需要牢牢記住的第一點是：線程同步就是線程排隊。同步就是排隊。線程同步的目的就是避免線程「同步」執行。這可真是個無聊的繞口令。
關於線程同步，需要牢牢記住的第二點是 「共享」這兩個字。只有共享資源的讀寫訪問才需要同步。如果不是共享資源，那麼就根本沒有同步的必要。
關於線程同步，需要牢牢記住的第三點是，只有「變數」才需要同步訪問。如果共享的資源是固定不變的，那麼就相當於「常量」，線程同時讀取常量也不需要同步。至少一個線程修改共享資源，這樣的情況下，線程之間就需要同步。
關於線程同步，需要牢牢記住的第四點是：多個線程訪問共享資源的代碼有可能是同一份代碼，也有可能是不同的代碼；無論是否執行同一份代碼，只要這些線程的代碼訪問同一份可變的共享資源，這些線程之間就需要同步。
為了加深理解，下面舉幾個例子。
有兩個采購員，他們的工作內容是相同的，都是遵循如下的步驟：
（1）到市場上去，尋找並購買有潛力的樣品。
（2）回到公司，寫報告。
這兩個人的工作內容雖然一樣，他們都需要購買樣品，他們可能買到同樣種類的樣品，但是他們絕對不會購買到同一件樣品，他們之間沒有任何共享資源。所以，他們可以各自進行自己的工作，互不幹擾。
這兩個采購員就相當於兩個線程；兩個采購員遵循相同的工作步驟，相當於這兩個線程執行同一段代碼。
下面給這兩個采購員增加一個工作步驟。采購員需要根據公司的「布告欄」上面公布的信息，安排自己的工作計劃。
這兩個采購員有可能同時走到布告欄的前面，同時觀看布告欄上的信息。這一點問題都沒有。因為布告欄是只讀的，這兩個采購員誰都不會去修改布告欄上寫的信息。
下面增加一個角色。一個辦公室行政人員這個時候，也走到了布告欄前面，准備修改布告欄上的信息。
如果行政人員先到達布告欄，並且正在修改布告欄的內容。兩個采購員這個時候，恰好也到了。這兩個采購員就必須等待行政人員完成修改之後，才能觀看修改後的信息。
如果行政人員到達的時候，兩個采購員已經在觀看布告欄了。那麼行政人員需要等待兩個采購員把當前信息記錄下來之後，才能夠寫上新的信息。
上述這兩種情況，行政人員和采購員對布告欄的訪問就需要進行同步。因為其中一個線程（行政人員）修改了共享資源（布告欄）。而且我們可以看到，行政人員的工作流程和采購員的工作流程（執行代碼）完全不同，但是由於他們訪問了同一份可變共享資源（布告欄），所以他們之間需要同步。
同步鎖
前面講了為什麼要線程同步，下面我們就來看如何才能線程同步。
線程同步的基本實現思路還是比較容易理解的。我們可以給共享資源加一把鎖，這把鎖只有一把鑰匙。哪個線程獲取了這把鑰匙，才有權利訪問該共享資源。
生活中，我們也可能會遇到這樣的例子。一些超市的外面提供了一些自動儲物箱。每個儲物箱都有一把鎖，一把鑰匙。人們可以使用那些帶有鑰匙的儲物箱，把東西放到儲物箱裡面，把儲物箱鎖上，然後把鑰匙拿走。這樣，該儲物箱就被鎖住了，其他人不能再訪問這個儲物箱。（當然，真實的儲物箱鑰匙是可以被人拿走復制的，所以不要把貴重物品放在超市的儲物箱裡面。於是很多超市都採用了電子密碼鎖。）
線程同步鎖這個模型看起來很直觀。但是，還有一個嚴峻的問題沒有解決，這個同步鎖應該加在哪裡？
當然是加在共享資源上了。反應快的讀者一定會搶先回答。
沒錯，如果可能，我們當然盡量把同步鎖加在共享資源上。一些比較完善的共享資源，比如，文件系統，資料庫系統等，自身都提供了比較完善的同步鎖機制。我們不用另外給這些資源加鎖，這些資源自己就有鎖。
但是，大部分情況下，我們在代碼中訪問的共享資源都是比較簡單的共享對象。這些對象裡面沒有地方讓我們加鎖。
讀者可能會提出建議：為什麼不在每一個對象內部都增加一個新的區域，專門用來加鎖呢？這種設計理論上當然也是可行的。問題在於，線程同步的情況並不是很普遍。如果因為這小概率事件，在所有對象內部都開辟一塊鎖空間，將會帶來極大的空間浪費。得不償失。
於是，現代的編程語言的設計思路都是把同步鎖加在代碼段上。確切的說，是把同步鎖加在「訪問共享資源的代碼段」上。這一點一定要記住，同步鎖是加在代碼段上的。
同步鎖加在代碼段上，就很好地解決了上述的空間浪費問題。但是卻增加了模型的復雜度，也增加了我們的理解難度。
現在我們就來仔細分析「同步鎖加在代碼段上」的線程同步模型。
首先，我們已經解決了同步鎖加在哪裡的問題。我們已經確定，同步鎖不是加在共享資源上，而是加在訪問共享資源的代碼段上。
其次，我們要解決的問題是，我們應該在代碼段上加什麼樣的鎖。這個問題是重點中的重點。這是我們尤其要注意的問題：訪問同一份共享資源的不同代碼段，應該加上同一個同步鎖；如果加的是不同的同步鎖，那麼根本就起不到同步的作用，沒有任何意義。
這就是說，同步鎖本身也一定是多個線程之間的共享對象。
Java語言的synchronized關鍵字
為了加深理解，舉幾個代碼段同步的例子。
不同語言的同步鎖模型都是一樣的。只是表達方式有些不同。這里我們以當前最流行的Java語言為例。Java語言裡面用synchronized關鍵字給代碼段加鎖。整個語法形式表現為
synchronized(同步鎖) {
// 訪問共享資源，需要同步的代碼段
}
這里尤其要注意的就是，同步鎖本身一定要是共享的對象。
… f1() {
Object lock1 = new Object(); // 產生一個同步鎖
synchronized(lock1){
// 代碼段 A
// 訪問共享資源 resource1
// 需要同步
}
}
上面這段代碼沒有任何意義。因為那個同步鎖是在函數體內部產生的。每個線程調用這段代碼的時候，都會產生一個新的同步鎖。那麼多個線程之間，使用的是不同的同步鎖。根本達不到同步的目的。
同步代碼一定要寫成如下的形式，才有意義。
public static final Object lock1 = new Object();
… f1() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 A
// 訪問共享資源 resource1
// 需要同步
}
你不一定要把同步鎖聲明為static或者public，但是你一定要保證相關的同步代碼之間，一定要使用同一個同步鎖。
講到這里，你一定會好奇，這個同步鎖到底是個什麼東西。為什麼隨便聲明一個Object對象，就可以作為同步鎖？
在Java裡面，同步鎖的概念就是這樣的。任何一個Object Reference都可以作為同步鎖。我們可以把Object Reference理解為對象在內存分配系統中的內存地址。因此，要保證同步代碼段之間使用的是同一個同步鎖，我們就要保證這些同步代碼段的synchronized關鍵字使用的是同一個Object Reference，同一個內存地址。這也是為什麼我在前面的代碼中聲明lock1的時候，使用了final關鍵字，這就是為了保證lock1的Object Reference在整個系統運行過程中都保持不變。
一些求知慾強的讀者可能想要繼續深入了解synchronzied(同步鎖)的實際運行機制。Java虛擬機規范中（你可以在google用「JVM Spec」等關鍵字進行搜索），有對synchronized關鍵字的詳細解釋。synchronized會編譯成 monitor enter, … monitor exit之類的指令對。Monitor就是實際上的同步鎖。每一個Object Reference在概念上都對應一個monitor。
這些實現細節問題，並不是理解同步鎖模型的關鍵。我們繼續看幾個例子，加深對同步鎖模型的理解。
public static final Object lock1 = new Object();
… f1() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 A
// 訪問共享資源 resource1
// 需要同步
}
}
… f2() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 B
// 訪問共享資源 resource1
// 需要同步
}
}
上述的代碼中，代碼段A和代碼段B就是同步的。因為它們使用的是同一個同步鎖lock1。
如果有10個線程同時執行代碼段A，同時還有20個線程同時執行代碼段B，那麼這30個線程之間都是要進行同步的。
這30個線程都要競爭一個同步鎖lock1。同一時刻，只有一個線程能夠獲得lock1的所有權，只有一個線程可以執行代碼段A或者代碼段B。其他競爭失敗的線程只能暫停運行，進入到該同步鎖的就緒（Ready）隊列。
每一個同步鎖下面都掛了幾個線程隊列，包括就緒（Ready）隊列，待召（Waiting）隊列等。比如，lock1對應的就緒隊列就可以叫做lock1 - ready queue。每個隊列裡面都可能有多個暫停運行的線程。
注意，競爭同步鎖失敗的線程進入的是該同步鎖的就緒（Ready）隊列，而不是後面要講述的待召隊列（Waiting Queue，也可以翻譯為等待隊列）。就緒隊列裡面的線程總是時刻准備著競爭同步鎖，時刻准備著運行。而待召隊列裡面的線程則只能一直等待，直到等到某個信號的通知之後，才能夠轉移到就緒隊列中，准備運行。
成功獲取同步鎖的線程，執行完同步代碼段之後，會釋放同步鎖。該同步鎖的就緒隊列中的其他線程就繼續下一輪同步鎖的競爭。成功者就可以繼續運行，失敗者還是要乖乖地待在就緒隊列中。
因此，線程同步是非常耗費資源的一種操作。我們要盡量控制線程同步的代碼段范圍。同步的代碼段范圍越小越好。我們用一個名詞「同步粒度」來表示同步代碼段的范圍。
同步粒度
在Java語言裡面，我們可以直接把synchronized關鍵字直接加在函數的定義上。
比如。
… synchronized … f1() {
// f1 代碼段
}
這段代碼就等價於
… f1() {
synchronized(this){ // 同步鎖就是對象本身
// f1 代碼段
}
}
同樣的原則適用於靜態（static）函數
比如。
… static synchronized … f1() {
// f1 代碼段
}
這段代碼就等價於
…static … f1() {
synchronized(Class.forName(…)){ // 同步鎖是類定義本身
// f1 代碼段
}
}
但是，我們要盡量避免這種直接把synchronized加在函數定義上的偷懶做法。因為我們要控制同步粒度。同步的代碼段越小越好。synchronized控制的范圍越小越好。
我們不僅要在縮小同步代碼段的長度上下功夫，我們同時還要注意細分同步鎖。
比如，下面的代碼
public static final Object lock1 = new Object();
… f1() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 A
// 訪問共享資源 resource1
// 需要同步
}
}
… f2() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 B
// 訪問共享資源 resource1
// 需要同步
}
}
… f3() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 C
// 訪問共享資源 resource2
// 需要同步
}
}
… f4() {
synchronized(lock1){ // lock1 是公用同步鎖
// 代碼段 D
// 訪問共享資源 resource2
// 需要同步
}
}
上述的4段同步代碼，使用同一個同步鎖lock1。所有調用4段代碼中任何一段代碼的線程，都需要競爭同一個同步鎖lock1。
我們仔細分析一下，發現這是沒有必要的。
因為f1()的代碼段A和f2()的代碼段B訪問的共享資源是resource1，f3()的代碼段C和f4()的代碼段D訪問的共享資源是resource2，它們沒有必要都競爭同一個同步鎖lock1。我們可以增加一個同步鎖lock2。f3()和f4()的代碼可以修改為：
public static final Object lock2 = new Object();
… f3() {
synchronized(lock2){ // lock2 是公用同步鎖
// 代碼段 C
// 訪問共享資源 resource2
// 需要同步
}
}
… f4() {
synchronized(lock2){ // lock2 是公用同步鎖
// 代碼段 D
// 訪問共享資源 resource2
// 需要同步
}
}
這樣，f1()和f2()就會競爭lock1，而f3()和f4()就會競爭lock2。這樣，分開來分別競爭兩個鎖，就可以大大較少同步鎖競爭的概率，從而減少系統的開銷。
信號量
同步鎖模型只是最簡單的同步模型。同一時刻，只有一個線程能夠運行同步代碼。
有的時候，我們希望處理更加復雜的同步模型，比如生產者/消費者模型、讀寫同步模型等。這種情況下，同步鎖模型就不夠用了。我們需要一個新的模型。這就是我們要講述的信號量模型。
信號量模型的工作方式如下：線程在運行的過程中，可以主動停下來，等待某個信號量的通知；這時候，該線程就進入到該信號量的待召（Waiting）隊列當中；等到通知之後，再繼續運行。
很多語言裡面，同步鎖都由專門的對象表示，對象名通常叫Monitor。
同樣，在很多語言中，信號量通常也有專門的對象名來表示，比如，Mutex，Semphore。
信號量模型要比同步鎖模型復雜許多。一些系統中，信號量甚至可以跨進程進行同步。另外一些信號量甚至還有計數功能，能夠控制同時運行的線程數。
我們沒有必要考慮那麼復雜的模型。所有那些復雜的模型，都是最基本的模型衍生出來的。只要掌握了最基本的信號量模型——「等待/通知」模型，復雜模型也就迎刃而解了。
我們還是以Java語言為例。Java語言裡面的同步鎖和信號量概念都非常模糊，沒有專門的對象名詞來表示同步鎖和信號量，只有兩個同步鎖相關的關鍵字——volatile和synchronized。
這種模糊雖然導致概念不清，但同時也避免了Monitor、Mutex、Semphore等名詞帶來的種種誤解。我們不必執著於名詞之爭，可以專注於理解實際的運行原理。
在Java語言裡面，任何一個Object Reference都可以作為同步鎖。同樣的道理，任何一個Object Reference也可以作為信號量。
Object對象的wait()方法就是等待通知，Object對象的notify()方法就是發出通知。
具體調用方法為
（1）等待某個信號量的通知
public static final Object signal = new Object();
… f1() {
synchronized(singal) { // 首先我們要獲取這個信號量。這個信號量同時也是一個同步鎖
// 只有成功獲取了signal這個信號量兼同步鎖之後，我們才可能進入這段代碼
signal.wait(); // 這里要放棄信號量。本線程要進入signal信號量的待召（Waiting）隊列
// 可憐。辛辛苦苦爭取到手的信號量，就這么被放棄了
// 等到通知之後，從待召（Waiting）隊列轉到就緒（Ready）隊列裡面
// 轉到了就緒隊列中，離CPU核心近了一步，就有機會繼續執行下面的代碼了。
// 仍然需要把signal同步鎖競爭到手，才能夠真正繼續執行下面的代碼。命苦啊。
…
}
}
需要注意的是，上述代碼中的signal.wait()的意思。signal.wait()很容易導致誤解。signal.wait()的意思並不是說，signal開始wait，而是說，運行這段代碼的當前線程開始wait這個signal對象，即進入signal對象的待召（Waiting）隊列。
（2）發出某個信號量的通知
… f2() {
synchronized(singal) { // 首先，我們同樣要獲取這個信號量。同時也是一個同步鎖。
// 只有成功獲取了signal這個信號量兼同步鎖之後，我們才可能進入這段代碼
signal.notify(); // 這里，我們通知signal的待召隊列中的某個線程。
// 如果某個線程等到了這個通知，那個線程就會轉到就緒隊列中
// 但是本線程仍然繼續擁有signal這個同步鎖，本線程仍然繼續執行
// 嘿嘿，雖然本線程好心通知其他線程，
// 但是，本線程可沒有那麼高風亮節，放棄到手的同步鎖
// 本線程繼續執行下面的代碼
…
}
}
需要注意的是，signal.notify()的意思。signal.notify()並不是通知signal這個對象本身。而是通知正在等待signal信號量的其他線程。
以上就是Object的wait()和notify()的基本用法。
實際上，wait()還可以定義等待時間，當線程在某信號量的待召隊列中，等到足夠長的時間，就會等無可等，無需再等，自己就從待召隊列轉移到就緒隊列中了。
另外，還有一個notifyAll()方法，表示通知待召隊列裡面的所有線程。
這些細節問題，並不對大局產生影響。
綠色線程
綠色線程（Green Thread）是一個相對於操作系統線程（Native Thread）的概念。
操作系統線程（Native Thread）的意思就是，程序裡面的線程會真正映射到操作系統的線程，線程的運行和調度都是由操作系統控制的
綠色線程（Green Thread）的意思是，程序裡面的線程不會真正映射到操作系統的線程，而是由語言運行平台自身來調度。
當前版本的Python語言的線程就可以映射到操作系統線程。當前版本的Ruby語言的線程就屬於綠色線程，無法映射到操作系統的線程，因此Ruby語言的線程的運行速度比較慢。
難道說，綠色線程要比操作系統線程要慢嗎？當然不是這樣。事實上，情況可能正好相反。Ruby是一個特殊的例子。線程調度器並不是很成熟。
目前，線程的流行實現模型就是綠色線程。比如，stackless Python，就引入了更加輕量的綠色線程概念。在線程並發編程方面，無論是運行速度還是並發負載上，都優於Python。
另一個更著名的例子就是ErLang（愛立信公司開發的一種開源語言）。
ErLang的綠色線程概念非常徹底。ErLang的線程不叫Thread，而是叫做Process。這很容易和進程混淆起來。這里要注意區分一下。
ErLang Process之間根本就不需要同步。因為ErLang語言的所有變數都是final的，不允許變數的值發生任何變化。因此根本就不需要同步。
final變數的另一個好處就是，對象之間不可能出現交叉引用，不可能構成一種環狀的關聯，對象之間的關聯都是單向的，樹狀的。因此，內存垃圾回收的演算法效率也非常高。這就讓ErLang能夠達到Soft Real Time（軟實時）的效果。這對於一門支持內存垃圾回收的語言來說，可不是一件容易的事情。
7. 有沒有講怎樣使兩個線程並發執行的書，介紹下，謝謝！
應用程序；線程是系統分配處理器時間資源的基本單元，或者說進程之內獨立執行的一個單元。對於操作系統而言，其調度單元是線程。一個進程至少包括一個線程，通常將該線程稱為主線程。一個進程從主線程的執行開始進而創建一個或多個附加線程，就是所謂基於多線程的多任務。
那進程與線程的區別到底是什麼？進程是執行程序的實例。例如，當你運行記事本程序（Nodepad）時，你就創建了一個用來容納組成 Notepad.exe的代碼及其所需調用動態鏈接庫的進程。每個進程均運行在其專用且受保護的地址空間內。因此，如果你同時運行記事本的兩個拷貝，該程序正在使用的數據在各自實例中是彼此獨立的。在記事本的一個拷貝中將無法看到該程序的第二個實例打開的數據。
以沙箱為例進行闡述。一個進程就好比一個沙箱。線程就如同沙箱中的孩子們。孩子們在沙箱子中跑來跑去，並且可能將沙子攘到別的孩子眼中，他們會互相踢打或撕咬。但是，這些沙箱略有不同之處就在於每個沙箱完全由牆壁和頂棚封閉起來，無論箱中的孩子如何狠命地攘沙，他們也不會影響到其它沙箱中的其他孩子。因此，每個進程就象一個被保護起來的沙箱。未經許可，無人可以進出。
實際上線程運行而進程不運行。兩個進程彼此獲得專用數據或內存的唯一途徑就是通過協議來共享內存塊。這是一種協作策略。下面讓我們分析一下任務管理器里的進程選項卡。
這里的進程是指一系列進程，這些進程是由它們所運行的可執行程序實例來識別的，這就是進程選項卡中的第一列給出了映射名稱的原因。請注意，這里並沒有進程名稱列。進程並不擁有獨立於其所歸屬實例的映射名稱。換言之，如果你運行5個記事本拷貝，你將會看到5個稱為Notepad.exe的進程。它們是如何彼此區別的呢？其中一種方式是通過它們的進程ID，因為每個進程都擁有其獨一無二的編碼。該進程ID由Windows NT或Windows 2000生成，並可以循環使用。因此，進程ID將不會越編越大，它們能夠得到循環利用。第三列是被進程中的線程所佔用的CPU時間百分比。它不是CPU的編號，而是被進程佔用的CPU時間百分比。此時我的系統基本上是空閑的。盡管系統看上去每一秒左右都只使用一小部分CPU時間，但該系統空閑進程仍舊耗用了大約99%的CPU時間。
第四列，CPU時間，是CPU被進程中的線程累計佔用的小時、分鍾及秒數。請注意，我對進程中的線程使用佔用一詞。這並不一定意味著那就是進程已耗用的CPU時間總和，因為，如我們一會兒將看到的，NT計時的方式是，當特定的時鍾間隔激發時，無論誰恰巧處於當前的線程中，它都將計算到CPU周期之內。通常情況下，在大多數NT系統中，時鍾以10毫秒的間隔運行。每10毫秒NT的心臟就跳動一下。有一些驅動程序代碼片段運行並顯示誰是當前的線程。讓我們將CPU時間的最後10毫秒記在它的帳上。因此，如果一個線程開始運行，並在持續運行8毫秒後完成，接著，第二個線程開始運行並持續了2毫秒，這時，時鍾激發，請猜一猜這整整10毫秒的時鍾周期到底記在了哪個線程的帳上？答案是第二個線程。因此，NT中存在一些固有的不準確性，而NT恰是以這種方式進行計時，實際情況也如是，大多數32位操作系統中都存在一個基於間隔的計時機制。請記住這一點，因為，有時當你觀察線程所耗用的CPU總和時，會出現盡管該線程或許看上去已運行過數十萬次，但其CPU時間佔用量卻可能是零或非常短暫的現象，那麼，上述解釋便是原因所在。上述也就是我們在任務管理器的進程選項卡中所能看到的基本信息列。
什麼是線程?
究竟什麼是線程呢？正如在圖A中所示，一個線程是給定的指令的序列 (你所編寫的代碼)，一個棧(在給定的方法中定義的變數)，以及一些共享數據(類一級的變數)。線程也可以從全局類中訪問靜態數據。
棧以及可能的一些共享數據
每個線程有其自己的堆棧和程序計數器（PC）。你可以把程序計數器（PC）設想為用於跟蹤線程正在執行的指令，而堆棧用於跟蹤線程的上下文，上下文是當線程執行到某處時，當前的局部變數的值。雖然你可以編寫出在線程之間傳送數據的子程序，在正常情況下，一個線程不能訪問另外一個線程的棧變數。
一個線程必須處於如下四種可能的狀態之一，這四種狀態為：
初始態：一個線程調用了new方法之後，並在調用start方法之前的所處狀態。在初始態中，可以調用start和stop方法。
Runnable：一旦線程調用了start 方法，線程就轉到Runnable 狀態，注意，如果線程處於Runnable狀態，它也有可能不在運行，這是因為還有優先順序和調度問題。 阻塞/ NonRunnable：線程處於阻塞/NonRunnable狀態，這是由兩種可能性造成的：要麼是因掛起而暫停的，要麼是由於某些原因而阻塞的，例如包括等待IO請求的完成。 退出：線程轉到退出狀態，這有兩種可能性，要麼是run方法執行結束，要麼是調用了stop方法。
最後一個概念就是線程的優先順序，線程可以設定優先順序，高優先順序的線程可以安排在低優先順序線程之前完成。一個應用程序可以通過使用線程中的方法setPriority(int)，來設置線程的優先順序大小。
另外,站長團上有產品團購,便宜有保證
8. java 線程教材
《Java線程 高清晰中文第二版》中文第二版
前言
第一章 線程簡介
Java術語
線程概述
為什麼要使用線程？
總結
第二章 Java線程API
通過Thread類創建線程
使用Runable介面的線程
線程的生命周期
線程命名
訪問線程
線程的啟動、停止和連接
總結
第三章 同步技術
銀行的例子
非同步讀取數據
一個進行同步操作的類
同步塊
嵌套鎖
死鎖
返回到銀行的例子
同步靜態方法
總結
第四章 等待和通知
返回到銀行的例子
等待和通知
wait（）、notify（）和notifyAll（）
wait（）和sleep（）
線程中斷
靜態方法（有關同步的細節）
總結
第五章 Java線程編程的例子
數據結構和容器
簡單的同步例子
一個網路伺服器類
AsyncInputStream類
使用TCPServer和AsynclnputStream
總結
第六章 Java線程調度
線程調度概述
何時調度是重要的
調度和線程優先順序
常見的調度實現
本地調度支持
其他線程調度方法
總結
第七章 Java線程調度例子
線程池
循環調度
作業調度
總結
第八章 和同步相關的高級主題
同步術語
預防死鎖
鎖飢餓
非線程安全的類
總結
第九章 多處理器機器上的並行化
單線程程序並行化
內層循環線程化
循環輸出
多處理器擴展
總結
第十章 線程組
線程組概念
創建線程組
線程組方法
操作線程組
線程組、線程和安全
總結
附錄一 其他主題
附錄二 異常和錯誤
詞彙表
如果想要地址的話請留言，謝謝！
9. Java 線程
你大概不 懂線程運行機制。
你的main()相當與主線程，啟動 a.start();
線程後，你的主線程仍然在運行，而且線程啟動大概需要幾毫秒，
這個時間里main()線程仍然在向下執行a.set2();
所以你結果輸出是：先33333再是11111
那就
class TestThread extends Thread {
public static void main(String[] args) {
TestThread a = new TestThread();
a.set1();
try{
a.start();
a.join(); /等待線程結束
}catch(Exception e){
}
a.set2();
}
public void run(){
System.out.print("11111" + "\n");
return;
}
public void set1(){
System.out.print("22222" + "\n");
}
public void set2(){
System.out.print("33333" + "\n");
}
}
10. Java線程：什麼是線程
線程，有時被稱為輕量級進程(Lightweight Process，LWP），是程序執行流的最小單元。一個標準的線程由線程ID，當前指令指針(PC），寄存器集合和堆棧組成。另外，線程是進程中的一個實體，是被系統獨立調度和分派的基本單位，線程自己不擁有系統資源，只擁有一點兒在運行中必不可少的資源，但它可與同屬一個進程的其它線程共享進程所擁有的全部資源。一個線程可以創建和撤消另一個線程，同一進程中的多個線程之間可以並發執行。由於線程之間的相互制約，致使線程在運行中呈現出間斷性。線程也有就緒、阻塞和運行三種基本狀態。就緒狀態是指線程具備運行的所有條件，邏輯上可以運行，在等待處理機；運行狀態是指線程佔有處理機正在運行；阻塞狀態是指線程在等待一個事件（如某個信號量），邏輯上不可執行。每一個程序都至少有一個線程，若程序只有一個線程，那就是程序本身。
截取於網路：http://ke..com/item/%E7%BA%BF%E7%A8%8B