業精于勤荒于嬉,行成于思毀于隨

Oracle數據庫查詢一個月的記錄的sql語句:

select LASTUPDTIME from spprereg where
    (to_date('2005-5-1','YYYY-mm-dd')-LASTUPDTIME)<0  and
    (LAST_DAY(to_date('2005-5-1','YYYY-mm-dd'))-LASTUPDTIME)>0

這是我的一個朋友寫的，轉給大家看看。

　從某種意義上來說，打工真是害人不淺，長期的打工固化了人的思維，淡化了人的責任感，扼殺了人的創新思維，沒有成本概念，缺乏長遠規劃。最為關鍵的是，打工打得越久，看問題的視角就越悲觀，自己也就越自卑。
   
　　一群老板聚在一起，大家所交流的話題大多是商業環境，以及如何更好地發展生意等等。向對方展示的也是自己光輝燦爛的一面和發展的一面。
   
　　一群打工者聚集在一起，牢騷往往占了多數，罵老板刻薄，埋怨工作量大且與收入不對稱等等，很少有打工者對自己目前的狀況滿意的，向對方展示的也更多的是自己沒有得到重用沒有得到發揮的一面。當然，有牢騷未必是不重視自己的工作，因為“嫌貨的才是買貨的”。留心一下你就會發現，人在跳槽前反而異常平靜，而成天把跳槽掛嘴邊的人一般是那些一直做下去的人。
   
　　為什么打工者會選擇用語言而不是實干來獲得心理平衡呢？這與打工者抱著一個什么樣的心態在打工密不可分。
   
　　筆者從1994年出道，打了四年工，跳出來自己開公司當老板，因根基不穩，一年后破產，又出來打工，四年后，又跳出來開公司當老板。在每次從打工者到老板，又由老板到打工者的轉換過程中，都難免要經歷一次耗時數月的心態調整和角色轉換，逼著自己進行換位思考，每次的轉換與脫一次皮也差不了多少。
   
　　生意后來做大了，打算讓太太來幫我接管我原來的那家公司，我自己重開一家，可太太打了八年工，接管公司后卻把公司搞得亂七八糟。追查原因，原來太太還是按照打工的那一套在管理公司，我又足足花了兩年時間來幫助太太實現由一個打工者向老板的轉換。由此想到，如今報紙雜志電視上招商廣告到處飛，好像有點資本就可以當老板了，好像老板可以速成？其實這就是許多創業以失敗告終的原因。
   
　　根據自己在老板與打工者角色之間不斷轉換的過程，我總結出以下老板與打工者心態的幾點不同：
   
　　長遠目標與短期行為
   
　　作為一個真正意義上的老板，知道自己最終想要什么，要達到目標需要經過哪些過程，具備長遠眼光，擁有戰略意識。而作為打工者，著眼點也就是當前這兩三年，往往第一考慮的還是安全感，如何保住現有的飯碗，自然不會想得太遠，也不會太高。而且，很少有打工者能進行換位思考，站到老板的角度去看問題和考慮問題。也就造成很多打工者很難與老板溝通。
   
　　解決問題與完成工作
   
　　老板對一件工作的完成定義是指把某件事徹底被解決，今天能搞定的一定不拖到明天。而打工者會習慣性地把工作按照天數來分解，每天只完成部分工作，下班時間一到心里就習慣性地想回家，剩下的工作明天再做，在公司里多待一分鐘都不愿意。
   
　　單個環節與整個系統
   
　　打工者接到一個指派工作任務后，進行處理或是分解后轉交給其他同事，然后在他看來，這事就差不多算完了，反正他負責的這塊已經做完了，至于轉交出去的工作是否被保質保量按時完成，那就不是他要操心的范圍了。長此以往，許多打工者已經習慣只管自己的二畝三分地，嚴重缺少整體系統概念。而老板常常看的是整個任務的完成。
   
　　推脫責任與承擔失敗
   
　　在一個企業或是公司里，我們最常見到的就是在出現事故后，老板要追查責任人，大家異常統一、步調一致地互相推卸責任，極少有人會站出來承認自己工作的不足。打工打久了，遇到問題首先想到的是回避，然后就是設法推給別人。這樣一來，打工者也就愈加不可能從失敗和失利中學習、吸取教訓。其實，老板們的成長就是從一個個自己承擔失敗，并從中總結分析了問題原因所在、積累經驗而來的。
   
　　個人意識與聯合力量
   
　　很多的打工者腦海中都存在著個人英雄主義，總希望在一些事情上表露一下，在老板面前表表功，為了不被其他同事搶了功勞，所以有時候就會冒一定的風險（當然是以公司的資源為成本的）一個人單槍匹馬干點什么出來，當然，要是出了婁子，最后還得由公司承擔，很少有打工者們會從降低成本及風險、或是提高效率的角度出發，去主動聯合其他同事，共同完成某項任務。
   
　　大手大腳與成本概念
   
　　作為老板，公司的每一分錢的支出都會算作是成本，省下來的就是利潤，所以，精打細算是許多老板的習慣性思維和行為。而打工者們卻是大方得很，反正公司的資產是老板的，只要自己工作方便順手，浪費點又算什么，以至于許多打工者在自己做老板的時候，還改變不了在打工時養成的大手大腳的習慣。
   
　　辦事一條線和思維多樣化
   
　　條條大路通羅馬，完成工作不止一種方法，但打工者長期打工生涯下來，已經習慣了用單一思維去考慮問題，A事就用A類解決辦法，B事就用B類解決辦法，很少會去用超越性的思維來從多角度多方向來探討問題的解決辦法。
   
　　從某種意義上來說，打工真是害人不淺，長期的打工固化了人的思維，淡化了人的責任感，扼殺了人的創新思維，沒有成本概念，缺乏長遠規劃。最為關鍵的是，打工打得越久，看問題的視角就越悲觀，自己也就越自卑。
   
　　所以提醒各位，即使一時不能當老板，也要抱著老板的心態去打工

“嫁個有錢人”不如自己成為有錢人，你想發財嗎？你知道如何成為有錢人嗎？

1、做你真正感興趣的事——你會花很多時間在上面，因此你一定要感興趣才行，如果不是這樣的話，你不愿意把時間花在上面，就得不到成功。

2、自己當老板。為別人打工，你絕不會變成巨富，老板一心一意地縮減開支，他的目標不是使他的職員變成有錢人。

3、提供一種有實效的服務，或一種實際的產品。你要以寫作、繪畫或作曲變成百萬富翁的機會可以說是無限小，而你要在營造業、房地產、制造業發大財的機會比較大。記住，出版商賺的錢比作家多得多。

4、如果你堅持要用自己的靈感來創業？最好選擇娛樂業，在這方面，發財的速度相當快，流行歌曲和電視最理想。

5、不論你是演員或商人，盡量增加你的觀眾。在小咖啡館唱歌的人，所賺的錢一定比不上替大唱片公司灌唱片的人，地方性的商人，不會比全國性的商人賺的錢多。

6、找出一種需要，然后滿足它。社會越變越復雜，人們所需要的產品和服務越來越多，最先發現這些需求而且滿足他們的人，是改進現有產品和服務的人，也是最先成為富翁的人。

7、不要不敢采用不同的方式——新的方法和新產品，會造成新的財富。但必須確定你的新方法比舊方法更理想，你的新方法必
想致富,請栽搖錢 引爆數碼影像!
中華川菜火鍋大聯 加盟樂可可天天樂

須增進產品外觀、效率、品質、方便或者降低成本。

8、如果你受過專業教育，或者有特殊才能，充分利用它。如果你燒得一手好菜，而卻要去當泥水匠，那就太笨了。

9、在你著手任何事情之前，仔細地對周圍的情形研究一番。政府機關和公共圖書館，可以提供不少資料，先做研究，可以節省你不少時間和金錢。

10、不要一直都想著發大財，不如你想想如何改進你的事業，您應該常常問自己的是：“我如何改良我的事業？”如何使事業進行順利，財富就會跟著而來。

11、可能的話，進行一種家庭事業，這種方法可以減少費用，增進士氣，利潤的分配很簡單，利潤能夠得到充分的利用，整個事業控制也較容易。

12、盡可能減少你的費用，但不能犧牲你的品質，否則的話，你等于是在慢性自殺，賺錢的機會不會大。

13、跟同行的朋友維持友誼——他們可能對你很有幫助。

14、把盡量多的時間花在事業上。一天12小時、一星期6天是最低要求，一天14小時到18小時很平常，一星期工作7天最好了。你必須先犧牲家庭和社會上的娛樂，直到你事業站穩為止。也只有到那時候，你才能把責任分給別人。

15、不要不敢自己下決心。聽聽別人的贊美和批評，但你自己要下決心。

16、不要不敢說實話。拐彎抹角，只會浪費時間，心里想什么就說什么，而且要盡可能地直截了當地、明確地說出來。

17、不要不敢承認自己的錯誤。犯了錯誤并不是一種罪行，犯錯不改才是罪過。

18、不要因為失敗就裹足不前。失敗是難免的，也是有價值的，從失敗中，你會學到正確的方法論。

19、不要在不可行的觀念上打轉。一發現某種方法行不通，立即把它放棄。世界上有無數的方法，把時間浪費在那些不可行的方法上是無可彌補的損失。

20、不要冒你承擔不起的風險。如果你損失10萬元，若損失得起的話，就可以繼續下去，但如果你賠不起5萬元，而一旦失敗的話，你就完蛋了。

21、一再投資，不要讓你的利潤空閑著，你的利潤要繼續投資下去，最好投資別的事業或你控制的事業上，那樣，才能錢滾錢，替你增加好幾倍的財富。

22、請一位高明的律師——他會替你節約更多的金錢和時間，比起你所給予的將要多的多。

23、請一位精明的會計師。最初的時候，你自己記賬，但除非你本身是個會計師，你還是請一位精明的會計師，可能決定你的成功和失敗——他是值得你花錢的。

24、請專家替你報稅。一位機靈的稅務專家，可又替你免很多的稅。

25、好好維持你的健康和你的平靜心靈——否則的話，擁有再多的錢也沒有什么意思。

多疑，敏感，天真，猶豫不決，膽怯，多慮

-如果有就趕快克服它。

 

1.了解你的精力充沛期。通常人們在早晨9點左右工作效率最高，可以把最困難的工作放到這時來完成。

　　2.集中一天中的頭兩個小時來處理手頭的工作并不接電話、不開會、不受打擾。這樣可以事半功倍。

　　3.立刻回復重要的郵件，將不重要的丟棄。若任它們積累成堆，反而更費時間。

　　4.做個任務清單，將所有的項目和約定記在效率手冊中。手頭一定要帶著效率手冊以幫助自己按計劃行事。

　　5.學會高效地利用零碎時間，用來讀點東西或是構思一個文件，不要發呆或做白日夢。

　　6.把瑣碎的工作寫在單子上，以便有零碎時間時馬上去做。

　　7.并非每件工作都值得精工細做，有些事只要過得去就可以了。一遍又一遍地寫些瑣碎的備忘錄不是高效利用時間的做法。

　　8.減少回電話的時間。如果你需要傳遞的只是一個信息，不妨在工作以外的時間在錄音電話上留言，或是發個電子郵件。

　　9.如果有人在電話中喋喋不休地講話，你可以禮貌地結束電話。

　　10.對可能打來的電話做到心中有數，這樣在你接到所期待的電話后便可迅速找到所需要的各種材料，不必當時亂翻亂找。

　　11.學習上網高效搜尋的技能，以節省上網查詢的時間。把你經常要瀏覽的網站收集起來以便隨時找到。

　　12.用國際互聯網簡化商業旅行的安排。多數飯店和航線可以網上查詢和預訂。

　　13.只要情況允許就可委派別人分擔工作。事必躬親會使自己疲憊不堪，而且永遠也做不完。不妨請同事幫忙，或讓助手更努力地投入。

　　14.做個靈活的日程表，當你需要時便可以忙中偷閑。例如，在中午加班，然后早一小時離開辦公室去健身，或是每天工作10個小時，然后用星期五來赴約會、看醫生。

　　15.在離開辦公室之前開列次日工作的清單，這樣第二天早晨一來便可以全力以赴。

Java中支持方法名相同，但是方法參數不同而自動去選擇執行哪一個方法，如print(int i)和print(String str),雖然方法名相同，但是參數不同。象這里的int和String 參數差異比較大所以看起來這種重載沒什么差別，但是如果是類型差別不大， 會出現什么情況呢？

   看下面的代碼：

    public void f(float i){
        System.out.println("float");
    }

    public viod f(double i){
       System.out.println("double");
   }

    那么執行 f(5)會輸出什么呢？5是被認為是float類型還是double類型還是會報錯呢？執行結果是 float 。原來在這種情況下，該數據類型能被轉為一個較大的數據類型，比5較大的數據類型是float,其次才到double,所以輸出結果是float。還有一個特殊的情況就是如果輸入類型為char,如這里我們執行f('a'),

不要以為這會出錯，其實是不會出錯的，因為如果沒有發現一個準確的char于它匹配，那么它就把這個char轉換成int類型，如果沒有int類型和它匹配，在去尋找較大的數據類型，這里它找到了float,所以這里執行flaot('a')輸出的還是 float。

  下面再討論另外一種情況，譬如說下面這種情況:

   定義了下面一個方法：

  public void f(int i){
    System.out.println("int ");
}

  如果執行f(100.99)會不會在這種數據類型大于這種重載方法期待的變量時會怎么處理呢？會不會把這種較大的數據類型縮小到期待的數據類型？編譯一下，很遺憾出錯了，在這種情況下是出錯的。

這么快就12點半了，睡覺了~~~不然明天早晨爬不起來了。

雖然Java中goto語句只是java的一個保留字，沒有起任何作用，但是我今天在使用continue和break語句時，還是發現了其中又goto語句的影子。因為continue和break語句都支持跳到一個Label的位置。下面是具體的用法：

  inner:
  for( int  i = 0 ; i<3 ;i++ ){
   System.out.println("iiii===>"+i); 
   for( int j =0 ; j<5; j++ ){
    if( j == 1 )
      continue  inner;
    System.out.println("j===>"+j); 
   }
  }

上面一段語句的輸出為

iiii===>0
j===>0
iiii===>1
j===>0
iiii===>2
j===>0

一般的 continue語句都是跳出當前循環，但是這個會跳出到標記inner的位置。

 

Java中檢查兩個對象是否相等，這個看起來很簡單的事情但是實際做起來不一定是一個簡單的事情。我們可能首先想到的是＝＝運算符號，但是這個運算符真的能比較兩個對象么？我們先看下面一段代碼：

   public static void main(String [] argv ){

        Integer    A = new Integer(47);

       Integer     B = new Integer(47);

      System.out.println( A == B ) ;

     System.out.println( A != B );

}

可能你覺得輸出的結果是true false ,但是結果正好相反，是：false,true。不要覺得奇怪，因為＝＝實際比較的是兩個對象的句柄，而不是對象的內容，所以 A==B輸出為false,    而A != B  輸出為false.

可能以為equals方法能幫我們解決這個問題，那么來試一下，

class Value {
  int i;
}

public class EqualsMethod2 {
  public static void main(String[] args) {
    Value v1 = new Value();
    Value v2 = new Value();
    v1.i = v2.i = 100;
    System.out.println(v1.equals(v2));
  }
} ///:~
結果輸出的并不是我們所希望的true,而是false,這是因為類默認的equal方法是直接比較句柄的，而不是我們所希望的比較內容，所以我們不得不發現我們要比較兩個類的內容我們不得不在類中重寫equal()方法來實現比較兩個類的內容。

 

原出處:http://dev.csdn.net/article/20/20614.shtm

(1) 類名首字母應該大寫。字段、方法以及對象（句柄）的首字母應小寫。對于所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定義中出現了常數初始化字符，則大寫static final基本類型標識符中的所有字母。這樣便可標志出它們屬于編譯期的常數。
Java包（Package）屬于一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對于域名擴展名稱，如com，org，net或者edu等，全部都應小寫（這也是Java 1.1和Java 1.2的區別之一）。

(2) 為了常規用途而創建一個類時，請采取“經典形式”，并包含對下述元素的定義：

equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable

(3) 對于自己創建的每一個類，都考慮置入一個main()，其中包含了用于測試那個類的代碼。為使用一個項目中的類，我們沒必要刪除測試代碼。若進行了任何形式的改動，可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。

(4) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類接口部分。理想情況下，方法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便于類內代碼的重復使用（有些時候，方法必須非常大，但它們仍應只做同樣的一件事情）。

(5) 設計一個類時，請設身處地為客戶程序員考慮一下（類的使用方法應該是非常明確的）。然后，再設身處地為管理代碼的人考慮一下（預計有可能進行哪些形式的修改，想想用什么方法可把它們變得更簡單）。
(6) 使類盡可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
■一個復雜的開關語句：考慮采用“多形”機制
■數量眾多的方法涉及到類型差別極大的操作：考慮用幾個類來分別實現
■許多成員變量在特征上有很大的差別：考慮使用幾個類

(7) 讓一切東西都盡可能地“私有”——private。可使庫的某一部分“公共化”（一個方法、類或者一個字段等等），就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的代碼，使他們不得不重新編寫和設計。若只公布自己必須公布的，就可放心大膽地改變其他任何東西。在多線程環境中，隱私是特別重要的一個因素——只有private字段才能在非同步使用的情況下受到保護。

(8) 謹惕“巨大對象綜合癥”。對一些習慣于順序編程思維、且初涉OOP領域的新手，往往喜歡先寫一個順序執行的程序，再把它嵌入一個或兩個巨大的對象里。根據編程原理，對象表達的應該是應用程序的概念，而非應用程序本身。

(9) 若不得已進行一些不太雅觀的編程，至少應該把那些代碼置于一個類的內部。

(10) 任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否采用內部類，從而改善編碼及維護工作（參見第14章14.1.2小節的“用內部類改進代碼”）。

(11) 盡可能細致地加上注釋，并用javadoc注釋文檔語法生成自己的程序文檔。

(12) 避免使用“魔術數字”，這些數字很難與代碼很好地配合。如以后需要修改它，無疑會成為一場噩夢，因為根本不知道“100”到底是指“數組大小”還是“其他全然不同的東西”。所以，我們應創建一個常數，并為其使用具有說服力的描述性名稱，并在整個程序中都采用常數標識符。這樣可使程序更易理解以及更易維護。

(13) 涉及構建器和異常的時候，通常希望重新丟棄在構建器中捕獲的任何異常——如果它造成了那個對象的創建失敗。這樣一來，調用者就不會以為那個對象已正確地創建，從而盲目地繼續。

(14) 當客戶程序員用完對象以后，若你的類要求進行任何清除工作，可考慮將清除代碼置于一個良好定義的方法里，采用類似于cleanup()這樣的名字，明確表明自己的用途。除此以外，可在類內放置一個boolean（布爾）標記，指出對象是否已被清除。在類的finalize()方法里，請確定對象已被清除，并已丟棄了從RuntimeException繼承的一個類（如果還沒有的話），從而指出一個編程錯誤。在采取象這樣的方案之前，請確定finalize()能夠在自己的系統中工作（可能需要調用System.runFinalizersOnExit(true)，從而確保這一行為）。

(15) 在一個特定的作用域內，若一個對象必須清除（非由垃圾收集機制處理），請采用下述方法：初始化對象；若成功，則立即進入一個含有finally從句的try塊，開始清除工作。

(16) 若在初始化過程中需要覆蓋（取消）finalize()，請記住調用super.finalize()（若Object屬于我們的直接超類，則無此必要）。在對finalize()進行覆蓋的過程中，對super.finalize()的調用應屬于最后一個行動，而不應是第一個行動，這樣可確保在需要基礎類組件的時候它們依然有效。

(17) 創建大小固定的對象集合時，請將它們傳輸至一個數組（若準備從一個方法里返回這個集合，更應如此操作）。這樣一來，我們就可享受到數組在編譯期進行類型檢查的好處。此外，為使用它們，數組的接收者也許并不需要將對象“造型”到數組里。

(18) 盡量使用interfaces，不要使用abstract類。若已知某樣東西準備成為一個基礎類，那么第一個選擇應是將其變成一個interface（接口）。只有在不得不使用方法定義或者成員變量的時候，才需要將其變成一個abstract（抽象）類。接口主要描述了客戶希望做什么事情，而一個類則致力于（或允許）具體的實施細節。

(19) 在構建器內部，只進行那些將對象設為正確狀態所需的工作。盡可能地避免調用其他方法，因為那些方法可能被其他人覆蓋或取消，從而在構建過程中產生不可預知的結果（參見第7章的詳細說明）。

(20) 對象不應只是簡單地容納一些數據；它們的行為也應得到良好的定義。

(21) 在現成類的基礎上創建新類時，請首先選擇“新建”或“創作”。只有自己的設計要求必須繼承時，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復雜。

(22) 用繼承及方法覆蓋來表示行為間的差異，而用字段表示狀態間的區別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是絕對應該避免的：應直接使用一個“顏色”字段。

(23) 為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，編譯器可能先找到同名的另一個類，并報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。

(24) 在Java 1.1 AWT中使用事件“適配器”時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，最后的結果就是新添加一個方法，而不是覆蓋現成方法。然而，由于這樣做是完全合法的，所以不會從編譯器或運行期系統獲得任何出錯提示——只不過代碼的工作就變得不正常了。

(25) 用合理的設計方案消除“偽功能”。也就是說，假若只需要創建類的一個對象，就不要提前限制自己使用應用程序，并加上一條“只生成其中一個”注釋。請考慮將其封裝成一個“獨生子”的形式。若在主程序里有大量散亂的代碼，用于創建自己的對象，請考慮采納一種創造性的方案，將些代碼封裝起來。

(26) 警惕“分析癱瘓”。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節。由于把握了全局，可快速認識自己未知的一些因素，防止在考察細節的時候陷入“死邏輯”中。

(27) 警惕“過早優化”。首先讓它運行起來，再考慮變得更快——但只有在自己必須這樣做、而且經證實在某部分代碼中的確存在一個性能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難于理解，而且難于維護。

(28) 請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易于理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對后來的人，它們都是相當重要的。如對此仍有懷疑，那么請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。

(29) 如認為自己已進行了良好的分析、設計或者實施，那么請稍微更換一下思維角度。試試邀請一些外來人士——并不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。采取這種方式，往往能在最適合修改的階段找出一些關鍵性的問題，避免產品發行后再解決問題而造成的金錢及精力方面的損失。

(30) 良好的設計能帶來最大的回報。簡言之，對于一個特定的問題，通常會花較長的時間才能找到一種最恰當的解決方案。但一旦找到了正確的方法，以后的工作就輕松多了，再也不用經歷數小時、數天或者數月的痛苦掙扎。我們的努力工作會帶來最大的回報（甚至無可估量）。而且由于自己傾注了大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑——那樣做往往得不償失。

(31) 可在Web上找到大量的編程參考資源，甚至包括大量新聞組、討論組、郵寄列表等。下面這個地方提供了大量有益的鏈接：

  Java中c中的指針的概念，但是我在使用中還是碰到過一些問題，如我把一個一個對象A賦值給對象B時，這兩個對象有一個改變，那么另外一個也相應的改變。下面分別談談這可能發生問題的幾種情況:

<一>從“一個對象到另一個對象的賦值”，如:

        Class  A = new Class();

       Class  B  = A;

       這種情況實際把句柄從一個地方復制到另外一個地方，這種情況下對象B和A實際指向的是同一個句柄，更新B會影響到A,同樣更新A也會影響到B。

<二>把對象作為方法的參數傳遞到一個方法中。Java方法的參數傳遞可以分成兩種：一種是值傳遞，這種一般是簡單的數據類型，如int,long,double,char這些等；一種類似是c中的引用傳遞，就是把對象作為一個引用傳遞給方法參數，在這種情況下，在方法中把這個傳入的參數對象改變，那么相應的傳入這個參數引用的對象也相應的改變。如:

     Number A = new Number();
     A.num   = 9;
     test(A);

     方法定義:

    public  void   test(Number n){
      n.num = 99;
    }

   那么A的num值會變成99.

<三>;把對象保存在ArrayList中.如果把一個對象保存在一個AyyayList中，如果這個對象再發生改變，那么在這個ArrayList中保存的對象也會改變，說白了還是兩個還是公用同一個句柄.如:

   Number A = new Number();
     A.num = 100;
     java.util.ArrayList list = new ArrayList();
     list.add(A);
     A.num = 999;
     Number B = (Number)list.get(0);
     System.out.println(B.num);

那么輸出為999,對象A的更改影響到了ArrayList中的保存的對象.