新寫了一個Java并發程序設計教程， 用于公司內部培訓的，和2007年寫的那個相比，內容更翔實一些。
內容列表
1、使用線程的經驗：設置名稱、響應中斷、使用ThreadLocal
2、Executor ：ExecutorService和Future ☆ ☆ ☆
3、阻塞隊列 : put和take、offer和poll、drainTo
4、線程間的協調手段：lock、condition、wait、notify、notifyAll ☆ ☆ ☆
5、Lock-free: atomic、concurrentMap.putIfAbsent、CopyOnWriteArrayList ☆ ☆ ☆
6、關于鎖使用的經驗介紹
7、并發流程控制手段：CountDownlatch、Barrier
8、定時器: ScheduledExecutorService、大規模定時器TimerWheel
9、并發三大定律：Amdahl、Gustafson、Sun-Ni
10、神人和圖書
11、業界發展情況: GPGPU、OpenCL
12、復習題
下載地址：
http://files.cnblogs.com/jobs/Java%e5%b9%b6%e5%8f%91%e7%a8%8b%e5%ba%8f%e8%ae%be%e8%ae%a1%e6%95%99%e7%a8%8b.pdf
歡迎看了之后寫反饋給我。
博客園的文章地址：
http://www.cnblogs.com/jobs/archive/2010/07/29/1788156.html
Google云計算AppEngine
Java版剛剛推出來的時候，我就申請了該服務。該服務的申請需要提供手機號碼驗證，GOOGLE很牛B，能夠發送全球的手機短信。申請的帳號放了很久，
前段時間學習OpenID，需要作一個范例，于是就在Google
AppEngine上作，作的過程發現其不能使用線程，導致HttpClient組件無法工作，于是我修改了OpenID4Java的實現，全部使用
URLConnection來實現。最終程序部署成功了，網址 http://cogito-study.appspot.com，歡迎大家測試使用。
我來說一下我對Google AppEngine Java版本的使用感受吧。
1、
Google AppEngine
Java版本，具備基本功能，但是由于缺乏一些重要的功能，例如線程，沒有線程，很多庫無法使用，例如我上面提到的HttpClient不能使用。
Google提供一個類的白名單http://code.google.com/intl/zh-CN/appengine/docs/java
/jrewhitelist.html，大多數需要使用的類都有，javax.xml.crypto不再其中，使得我要部署一個SAML2的實現時玩不
轉。
2、Google
AppEngine提供了一個DataStore，使用JDO訪問數據，其查詢語言支持GQL。基本功能是具備的，但是也是存在很大的局限性，最多返回
1000行數據，COUNT(*)也是最多返回1000行。這個限制使得很多應用要跑在其上，會很麻煩。
3、部署很簡單，在Eclipse中使用Google提供的插件，輸入帳號密碼就可以部署了，太簡單了。但我使用的過程中，經常出現某些時段無法部署的情況，通常遇到這種情況，多嘗試幾次或者過段時間再嘗試就好了。
4、管理界面簡潔方便，功能基本完備。包括性能監控、數據管理、日志、計費等都有。
總結
Google的AppEngine Java版本已經具備了基本功能，可以部署簡單應用了，但是由于其功能不夠完備，目前大多數應用要部署在其上，都會要做相當大的修改或者無法實現。
我在Google AppEngine上部署了一個Java應用(OpenID測試)
http://cogito-study.appspot.com
Google Apps不支持線程，所用到的庫openid4java需要創建線程（因為HttpClient），我修改了openid4java的實現，使得其支持Google App Engine。
部署在Google App Engine上的應用可以應用任何OpenID Provider登陸，包括Google、Yahoo、MSN等。
你可以通過這個測試網站了解OpenID
最近花了較多時間學習單點登陸以及相關的安全技術，做一個簡單的總結，發表我的一些看法。拋磚引玉，希望各位朋友參與討論。
單點登陸，鳥語原文為Single Sign-On，縮寫為SSO。別以為單點登陸是很時髦高深的技術，相反單點登陸是很古老的技術，例如1980年kerberos v4發布，一直發展至今，被Windows、Mac OS X、Linux等流行的操作系統所采用，是為應用最廣泛的單點登陸技術。
kerberos適用于局域網，十分成熟。互聯網發展之后，多個網站需要統一認證，業界需要適合互聯網的單點登陸技術，也就是WEB SSO。2002年，微軟提出了passport服務，由微軟統一提供帳號和認證服務，理所當然，大家都不愿意受制于微軟，但是很認同微軟提出WEB SSO理念，于是產生了Liberty Alliance，另外指定一套標準，這套標準發展起來就是SAML，目前SAML的版本是SAML V2，屬于OASIS的標準。
--------------
SAML
SAML，鳥語全名為Security Assertion Markup Language，彌漫著學院派的腐尸味道，縮寫十分怪異，令人望而生畏。計算機行業，向來崇尚時髦，SAML這一名稱使得其較少受到大眾程序員的關注。
SAML的標準制定者，來自SUN、BEA、IBM、RSA、AOL、Boeing等大公司，制定技術規范相當專業有水準，系統分層合理，抽象了幾個概念把整個系統描述得很清楚，使用流行技術XML Schema來描述協議，使用到了XML-Sign和XML Encrypt等較為前緣XML安全技術。
SAML的基本部分包括Protocol、Bingding、Profile、Metadata、AuthenticationContext。其中Protocol是交互消息的格式，例如AuthnRuequest/Response（認證請求/響應）的消息對。Bingding是指協議所采用的傳輸方式，例如使用HTTP Redirect或HTTP POST或SOAP的方式傳輸Protocol中所定義的消息。Profile是系統角色間交互消息的各種場景，例如Web Single Sign-ON是一種Profile、Single Sign-Out也是一種Profile、身份聯邦也是一種Profile。各個參與方所提供的服務的描述信息為metadata。系統的認證方法通常是千差萬別的，AuthenticationContext是SAML中定義的認證擴展點，可以是最普通的User Password認證，也可以是kerberos認證，也可以是電信常用的RADIUS，或者是動態密碼卡。
SAML在Java企業應用中，得到廣泛支持，IBM、BEA、ORACLE、SUN的Java應用服務器都提供了SAML的支持，曾經有人說，SAML就是如同JDBC一樣，將會是使系統集成的準入證。SAML有很多開源實現，包括SUN公司的Open SSO，不幸的是，這些開源實現都不夠好，或者相當糟糕，如果我們需要支持SAML協議，可能需要在開源的版本上裁剪或者另行開發。
SAML考慮了Web SSO，也考慮了傳統的SSO集成，包括Kerberos和LDAP的集成，其中Attributed擴展機制以及相關規范，使得SAML擁有良好的擴展性，很好集成傳統協議和支持新協議。
SAML是一個定義良好的規范，概念清晰，分層合理，擴展性良好，一切都很棒，但是有一點不好，就是曲高和寡！
-------------
OpenID
有一些互聯網公司，擁有眾多很多帳號，很牛B，例如GOOGLE、YAHOO、Facebook，希望別人的系統使用它們的帳號登陸。他們希望一種足夠簡單的WEB SSO規范，于是選擇一種草根網絡協議OpenID。OpenID，名字取得好，顧名思義，一看就知道它是干嘛的。國內也有它的Fans，例如豆瓣網。openID的確足夠簡單，但是協議本身是不完善，可能需要一些補充協議才能夠滿足業務需求。例如GOOGLE采用OpenID + OAuth。目前支持OpenID有Yahoo、Google、Windows Live，還有號稱要支持OpenID的Facebook。目前Yahoo和Google宣稱對OpenID的支持，但是其實是有限制的，Yahoo的OpenID只有少數合作伙伴才能獲得其屬性，Google也只有在其Google Apps中才能獲得賬號的Attribute。用戶賬號畢竟是一個互聯網公司的最寶貴資源，希望他們完全分享賬號是不可能的。
Open ID和SAML兩種規范，都將會減少系統間交互的成本，我們提供Open API時，應該支持其中一種或者或兩種規范。
--------------
OAuth
oAuth涉及到3大塊的交互和通信。1. 用戶，2. 擁有用戶資料/資源的服務器A，3. 求資源的服務器B，。
oAuth的典型應用場景（senario）
以前，用戶在 擁有資源 的的網站A有一大堆東西；現在用戶發現了一個新的網站B，比較好玩，但是這個新的網站B想調用 擁有資源的網站A的數據。
用戶在 求資源的網站B 上，點擊一個URL，跳轉到 擁有 資源的網站A。
擁有資源的網站A提示：你需要把資源分享給B網站嗎？Yes/No。
用戶點擊 Yes，擁有資源的網站A 給 求資源的網站B 臨時/永久 開一個通道，然后 求資源的網站 就可以來 擁有資源的網站 抓取所需的信息了。
(參考資料：http://initiative.yo2.cn/archives/633801）
（摘抄）
--------------
內部系統間集成使用LDAP、Kerberos，外部系統集成使用SAML或者OpenID + OAuth，這是一種建議的模式。
------------
PAM
人們尋找一種方案：一方面，將鑒別功能從應用中獨立出來，單獨進行模塊化設計，實現和維護；另一方面，為這些鑒別模塊建立標準 API，以便各應用程序能方便的使用它們提供的各種功能；同時，鑒別機制對其上層用戶（包括應用程序和最終用戶）是透明的。直到 1995 年，SUN 的研究人員提出了一種滿足以上需求的方案--插件式鑒別模塊（PAM）機制并首次在其操作系統 Solaris 2.3 上部分實現。插件式鑒別模塊（PAM）機制采用模塊化設計和插件功能，使得我們可以輕易地在應用程序中插入新的鑒別模塊或替換原先的組件,而不必對應用程序做任何修改，從而使軟件的定制、維持和升級更加輕松--因為鑒別機制與應用程序之間相對獨立。應用程序可以通過 PAM API 方便的使用 PAM 提供的各種鑒別功能，而不必了解太多的底層細節。此外，PAM的易用性也較強，主要表現在它對上層屏蔽了鑒別的具體細節，所以用戶不必被迫學習各種各樣的鑒別方式，也不必記住多個口令；又由于它實現了多鑒別機制的集成問題，所以單個程序可以輕易集成多種鑒別機制如 Kerberos 鑒別機制和 Diffie - Hellman 鑒別機制等，但用戶仍可以用同一個口令登錄而感覺不到采取了各種不同鑒別方法。PAM 后來被標準化為 X/Open UNIX® 標準化流程（在 X/Open 單點登錄服務（XSSO）架構中）的一部分。（摘抄）
如果我們設計一個認證系統，PAM是應該參考借鑒的。
-------------
JAAS
Java Authentication Authorization Service（JAAS，Java驗證和授權API）提供了靈活和可伸縮的機制來保證客戶端或服務器端的Java程序。Java早期的安全框架強調的是通過驗證代碼的來源和作者，保護用戶避免受到下載下來的代碼的攻擊。JAAS強調的是通過驗證誰在運行代碼以及他／她的權限來保護系統面受用戶的攻擊。它讓你能夠將一些標準的安全機制，例如Solaris NIS（網絡信息服務）、Windows NT、LDAP（輕量目錄存取協議），Kerberos等通過一種通用的，可配置的方式集成到系統中。在客戶端使用JAAS很簡單。在服務器端使用JAAS時情況要復雜一些。（摘抄）
-------------
Spring Security，Spring框架大名鼎鼎，Spring Security屬于SpringFramework旗下的一個子項目，源自acegi 1.x發展起來。很多人項目應用了spring security，但我個人看來，spring security絕對不算是一個設計良好的安全框架。其設計感覺就是一個小項目的安全認證實踐罷了。
-------------
CAS
應用最廣的開源單點登陸實現了，其實現模仿Kerberos的一些概念，例如KDC、TGS等等，都是來自于Kerberos。CAS對SAML和OpenID協議支持得不夠好。個人感覺類似Kerberos的機制在互聯網中可能過于復雜了。我感覺單純的ticket機制，過于局限于基于加密解密的安全了，感覺上SAML的Assertion概念更好，Assertion可以包括認證、授權以及屬性信息。
-------------
--------------------------
09博客園紀念T恤
新聞：
Wordpress發布實時RSS技術 推動實時網絡發展
網站導航:
博客園首頁 個人主頁 新聞 社區 博問 閃存 找找看
現在很多開源項目在使用LOG的時候做了不好的示范--在基類中實例化的方式使用LOG，而不是靜態變量。
例如：
class Base {
private final Log LOG = LogFactory.getLog(this.getClass());
}
class Derived {
public void foo() {
if (LOG.isDebugEnabled()) LOG.debug("foo");
}
}
這種用法，當類被繼承的時候，LOG就完全亂了。spring、struts都有這樣的問題。
正確的使用方式應該是直接靜態化聲明LOG。
例如：
class DerivedA {
private final static Log LOG = LogFactory.getLog(DerivedA.class);
}
--------------------------
盛大招聘.Net開發工程師
經典好書：.NET框架程序設計（修訂版）
新聞：
2008年最精彩科技圖片：電流運動模擬圖居首
導航：
博客園首頁 知識庫 新聞 招聘 社區 小組 博問 網摘 找找看
文章來源:
http://www.cnblogs.com/jobs/archive/2009/01/05/1368894.html
Eclipse包含很多插件，插件之間有復雜的依賴關系，如果使用單獨下載安裝的方式，容易遺失部分需要依賴的插件。
在Ecliipse的Software Update功能中安裝插件，能夠解決插件依賴的問題，但是在Eclipse 3.4之前的版本，Software Update不能夠多線程同時下載，遇到網速較慢的更新站點時，需要漫長的等待，有時候安裝一個插件，需要數個小時，甚至更久。
在Eclipse 3.4之后，Software Update有了很大的改變，可以多線程下載了，但是不能手工選擇鏡像，它會笨笨的選擇一些很慢的站點，效果變得更差了，下載速度時快時慢，但是經常都比以前手工選擇鏡像要慢。經常選擇一些只有數百B速度的下載站點，令人抓狂！
所以說，Eclipse 3.4的Software Update功能依然令失望。
期待數年，終于盼來了新版的Software Update功能，但是新版的更差了，哎。。。
摘要: 我們在開發中，經常需要遍歷一個目錄下的所有文件，常用的辦法就是使用一個函數遞歸遍歷是常用的辦法。但是遞歸函數的缺點就是擴展不方便，當然你對這個函數加入一個參數FileHandler，這樣擴展性稍好一些，但是仍然不夠好，比如說，不能根據遍歷的需要中途停止遍歷，加入Filter等等。我實現了一個FileIterator，使得遍歷一個目錄下的文件如何遍歷一個集合中的元素一般操作。
閱讀全文
http://openjdk.java.net/上的Announcements:
2008/04/28
New Project approved: More New I/O APIs for the Java
Platform
包括內容：
- 4313887 New
I/O: Improved filesystem interface
- 4640544 New
I/O: Complete socket-channel functionality
- 4607272 New
I/O: Support asynchronous I/O
讓人期待太久太久了，終于來了，Java在大規模并發、高性能方面又進一步，JSR 203應該會在JDK 7中實現，屆時隨著JDK 7的發布，將會有更多的基礎軟件使用Java實現，而且有極好的性能。
在磁盤I/O和網絡大規模并發I/O方面都會得到更好的性能。
可以預見受益的程序：
1、WEB服務器 Tomcat、Jetty等，在Windows下，Java將可以使用IOCP，而不是現在nio所用的select，網絡并發性能將會得到大幅度提升。在Linux下則應該改變不多，畢竟linux現在并發最好性能的網絡I/O EPOLL，JDK 6.0 nio的缺省實現就是epoll。
2、數據庫應用程序。如Derby、Berkeley DB Java Edition等使用Java實現的數據庫，性能將會得到更好的提升，有望能夠誕生和Oracle、SQL Server一樣強大的100% Pure Java的數據庫系統。
3、其他網絡應用程序。例如DNS、LDAP等，隨著MINA之類的框架更強大和JDK的原生支持，將會越來越多的服務器程序使用Java實現。
在新項目中，除了一些框架所依賴的配置文件使用XML外，基本沒有使用XML。JSON基本替代了原來XML在程序內的位置。在以前，我們不愿意使用一種私有的格式，于是選擇了XML。選擇XML的理由，可能是大家都用它，所以我們也用它。
XML 是一種很好的技術，但是目前的情況來看，XML被濫用了，SOAP是XML被濫用的一種典型，程序內部的表示使用XML也是濫用的一種典型。看到的一種情況，一個對象toString使用XML格式輸出，導致日志文件十分羅嗦，調試時，在watch窗口中看到一大堆<tag>。
在新項目中，認真考慮這種情況，找到了另外一種選擇，那就是JSON。選擇JSON的理由很充分：
1、JSON的解釋性能要比XML要好，要簡潔緊湊。
2、可讀性要比XML好。JSON本身就是JavaScript的語法，和程序員的思維，而非文檔編寫的思維。
3、JavaScript原生支持，客戶端瀏覽器不需要為此使用額外的解釋器，在web環境中使用特別合適。
在java中使用json，目前需要注意一些情況：
1、目前開源的JSON-LIB代碼質量不好，最好是在此基礎之上修改一個版本，或者自己重新開發一個版本。
2、使用new Date的方式替代JSON-LIB中的{year:2007, month:12, ....}之類的方式
3、JSON-LIB中，object的propertyName在輸出的時候，都帶上""，例如{"name": "溫少"}, 其中name是的雙引號是不必要的，在輸出時應該判斷，不需要的就是就不加上""，減少網絡流量。
4、JSON的解釋器中，應該支持簡單的表達式，例如new Date()、new Date(2939234723)之類的，這使得JSON的表達能力會更強一些。
5、JSON應該分兩種，一種只支持簡單格式，類似開源的JSON-LIB，一種是通過JavaScript解釋器來實現的。后者在程序中傳輸數據時，能夠得到更強大的表達能力，但是也會導致安全問題，需要慎重使用。
1、
XP中的結對編程。XP編程中，有一些思想總結的很好，例如測試驅動，但又有極度的荒唐的就是結對編程。結對編程是我看到過的最荒唐最可笑的軟件工程方
法，兩倍的投入，一半的產出，可謂事倍功半。以前看結對編程只是覺得荒唐可笑，后來看了李安的電影《斷背山》，覺得以“斷背”來形容結對編程最適合了，結
對編程簡直就是專門為“男同志”們度身定做的軟件工程方法，你想一對“男同志”，每天手牽手背靠背進行“結對編程”，是多么“浪漫有趣”的事情。不過這只
對“男同志”們的浪漫有趣，對工作本身一點也不有趣！
--------------
2、JDO投票鬧劇（2004-2005）。
一個通過黑客式靜態AOP方式旁門左道實現的持久化技術JDO，竟然會被一些人追捧，這本身就是一個很荒唐的事情了。在JCP的投票中，JDO被否決了，
這一點也不奇怪，奇怪的是投票結果出來之后的鬧劇。一些人以“政治陰謀論”來說事，說JDO不被通過，是因為政治原因，而非技術原因，這個荒唐的理由竟然
被社區的很多人相信了，一片聲討，JCP迫于壓力，重新投票，通過了JDO相關的JSR。但是JDO并沒有因此有一點點起色，一直沉淪至今。JDO通過靜
態AOP（enhance）的方式使得代碼無法調試，就單這一點，就足以使JDO永遠無法流行。
這件事情很明確表明兩點：1)、不要相信一些技術作家的判斷力；2)、普通的大眾沒有判斷能力，會人云亦云。
當年荒唐的文章選錄：
《程序員》2005年第2期 http://blog.csdn.net/gigix/archive/2005/01/21/262163.aspx
---------------
竟
然64個annotation，沒有分類，放在同一個package下，同一個package（javax.persistance）還有其他java文
件，共有88個java文件。不看內容本身，單從表面，都覺得這是混亂不堪的事情。這是那個豬頭的杰作？glassfish上下載的源碼中，這些java
文件似乎都沒有author，估計也不好意思把名字放出來見人吧！
------
覺得對象關系存儲方面一直沒有突破，也沒有好的產品出來，其中一個原因，就是從沒有過優秀的工程師投身過這個領域。關系數據庫為什么能夠一直堅守領地，成為絕大多數商業應用的基石，其中一個原因就是有過大量的精英投身于此，包括兩個圖靈獎獲得者。
關
系數據庫，為了描述關系，創造一門SQL語言，將關系一些操作，例如投影（select）、選擇（where）、分組(group
by)等等，抽象得形象易懂，功能強大。對于數據的操作，SQL語言是最強大，也是最方便的，也是最易于使用的。一些非程序員的IT從業人員，非計算機專
業的人員都能夠熟練掌握SQL。
OO和Relational都是偉大的技術，從計算機最高榮譽獎可以看出這兩個技術的偉大。OO的圖靈獎獲得者是三個，Relational的圖靈獎獲得者是兩個。
面向對象技術自1967年simula引進以來，所想披靡，93年-98年從C++開始流行，然后到Java，成為主流編程技術。Relational沒有OO那么輝煌，但是在數據存儲方面的地位固如磐石，長期占據絕對的地位。
曾
經OO技術涉足于數據存儲領域，但終究沒有成功。面向對象數據庫的變現總是差強人意，面向對象的方式操作數據，總是不如使用關系那么方便，那么靈活，那么
易于使用，那么好的性能。于是人們在數據存儲和處理方面，不在青睞面向對象技術，而是仍然使用關系方式，使用SQL語言，使用關系運算操作數據。面向對象
數據庫成了曇花一現的東西，并且可能永遠都不會再流行了。
OO成了主流編程技術，Relational占據了絕對的數據存儲地位，這兩大技術需要交互，需要橋接，這需要OR-Mapping。Relational雖然好，但我們也要與時俱進，所以也需要OR-Mapping。
但
是，做OR-Mapping時，不積極吸取relational方式對數據處理的靈活性、方便性、簡單性，而只強調Relational和對象之間的的
Mapping，試圖以面向對象的方式操作數據，這是錯誤的方向。以前的EJB、現在Hibernate、JPA都犯了同樣的錯誤，試圖以更面向對象的方
式操作數據，從而導致復雜混亂的模型，這也是JPA的現狀吧。例如user.getGroup()，目前的ORM試圖以純OO的方式操作數據，所引起的
LazyLoad、n+1等問題，使得事情變得復雜而且混亂不堪。
一些開發人員，去學習Hibernate，不學習SQL，有人提倡，只需要了解面向對象編程技術，不需要了解關系技術，亦屬于本末倒置。需求人員都會用的SQL語言，對數據操作最方便最簡單最強大的SQL語言，竟然成了令人生畏的紙老虎，可笑啊。
-------------
以下是過去的一些業界浮躁不理智：
1、面向對象數據庫。曾被熱衷而吹捧，面向對象數據庫的變現總是差強人意，面向對象的方式操作數據，總是不如使用關系那么方便，那么靈活，那么易于使用，那么好的性能。于是人們在數據存儲和處
理方面，不在青睞面向對象技術，而是仍然使用關系方式，使用SQL語言，使用關系運算操作數據。面向對象數據庫成了曇花一現的東西，并且可能永遠都不會再
流行了。
2、
JDO投票鬧劇。2004-2005年，JDO的JSR在JCP投票被否決的，無聊者在Java社區以及媒體發起鬧事，陰謀論其為政治謀殺，幾大公司是的
迫于形象，重新投票使得JDO被通過，但JDO這種靜態AOP叫雕蟲小計式技術，不單開發過程不方便，而且會使得"enhance"之后的代碼不可調試。
這完全是對開發者不友好的技術，沒有前途的技術，竟然會有人為它在JCP投票不通過鳴不平。這件事情使得我更堅信一點，不要相信那些技術編輯的判斷力。
3、
AOP。也是最近這幾年流行的一個名詞了。起了一個和OOP相似的名字，但是和偉大的OOP相比，它完全不算是什么。AOP只是一種很小很小的技巧而已，
靜態的AOP是黑客式的插入代碼，會導致代碼不可調試，動態的AOP能力有限，AOP最常被引用例子“日志AOP”是不合適，有用的日志通常是精心設計
的，AOP方式的日志在生產環境中基本上是不可用。OO這么多年，這么為偉大，人們總是希望自己能做點什么和偉大的OO相比，于是命名為AOP，這是一個
可笑的名字，前些年還有人談論面向對象的未來是面向事實，也是同樣的可笑。AOP有價值，但它是一種小技巧，和名字不般配。
--------------
目前在流行，但是可能是不理智的技術：
1、hibernate之類的ORM，試圖以面向對象方式操作數據，和面向對象數據庫一樣，重蹈覆轍。
2、Ruby，一個小腳本語言，只是因為動態類型、mixin之類的功能，還沒有被證明有生產力，有效益可用的腳本語言，就被媒體吹到天上去。Ruby有價值，但是最終結果會離大家的期待相差甚遠。