活到老，學到老

     摘要:     概念：觀察者模式定義了一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知并自動更新。     舉個網上商城的例子，比如很多顧客對某個商品感興趣，把商品收藏，當該商品降價、促銷、有貨了等事件發生時，就會發Email通知顧客。     UML圖...  閱讀全文

    從今天開始，把常用的設計模式都簡單的整理一遍，希望每個星期能至少整理2個模式吧，先從簡單的策略模式開始。
    
    概念：它定義了一系列的算法，并將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法的變化不會影響到使用算法的客戶。
    
    策略模式很簡單，實際上就是OO中的多態，舉個例子，某商場要進行促銷，對于普通顧客打88折，對于銀卡客戶在88折基礎上再滿400減160，對于金卡客戶在88折基礎上再滿400減200。
    
    UML圖如下所示：
    

    接口DiscountStrategy代碼如下：
    

public interface DiscountStrategy {
    public double discount(double sum);
}

    類GeneralDiscountStrategy類代碼如下：
    
    類SilverDiscountStrategy類代碼如下：
    
    類GoldenDiscountStrategy代碼如下：
    
    類Cashier代碼如下：
    

     摘要:     這篇寫一個簡單的HelloWorld例子。     首先準備環境，我使用的JDK1.6,1.5應該也可以。還需要去oracle下載JMX RI包，地址為：http://www.oracle.com/technetwork/java/javase/tech/download-jsp-141676.html，下載...  閱讀全文

    這是我讀了JMX In Action以后的總結，這篇文章是這個系列的第一篇，主要介紹一下什么是JMX，為什么要使用JMX？以及簡單闡述一下JMX的架構。
    什么是JMX？
    首先看一下維基百科的定義：JMX（Java Management Extensions，即Java管理擴展）是Java平臺上為應用程序、設備、系統等植入管理功能的框架。
JMX可以跨越一系列異構操作系統平臺、系統體系結構和網絡傳輸協議，靈活的開發無縫集成的系統、網絡和服務管理應用。
    隨著企業 IT 規模的不斷增長，IT 資源（IT resource）數量不斷增加，IT 資源的分布也越來越分散。IT資源主要包括網絡和應用等。管理網絡（硬件）的主要工具是
簡單網絡管理協議（SNMP），硬件廠商一般都會在設備中提供SNMP hooks，但SNMP開發不是件容易的事情，而且需要掌握特定的語言，對JAVA開發者絕非易事。
    有些企業開發的應用的時候，是不會考慮運行時配置和管理問題。有些企業直接在產品中開發管理工具和界面。也有一些企業直接使用應用服務器或web服務器的管理工具。
    現實世界的IT資源管理需求主要有以下一些：
    1、監控平臺和硬件的健康。硬件可以通過SNMP，WEB服務器和應用服務器可以通過他們自己的管理工具。數據庫也是一樣等。
   2、配置應用層面的資源。比如配置應用在查詢結果中每頁顯示的數量，配置數據庫連接池，或者外部請求數等。
   3、收集應用程序的統計信息。如多少成功訂單，多少失敗訂單等。
   4、日志級別，改變日志級別。出問題的時候，可以通過改變日志級別來打印調試信息，快速定位問題。
   5、監視服務器的性能、負載，通過email、sms等通知關鍵性事件，比如服務器負載超過預設的界限。
    要滿足這些需求往往是非常昂貴和困難的，管理員通常需要通過不同的工具來管理不同的服務和硬件。 如果使用JMX，創建一個滿足上面需求的管理系統將是廉價、更加靈活、所需時間更短。     
    
    使用JMX的好處
     1、非常容易使用。特別是對一個JAVA程序員，要理解SNMP是困難的。而JMX對他來說非常容易。
      2、利用現有的技術：現有的管理工具可以插入JMX，JMX提供了很多協議（SNMP、HTTP）和傳輸方式（如RMI），如果原有的應用和設備沒有提供管理能力，則可以創建JMX代理提供管理能力。
      3、模塊化。以模塊化的方式創建你的管理環境。
      4、警告、事件和統計信息。
        JMX提供了一套通知系統，充分利用了面向對象優勢，通知提供了不僅僅是數據，而是一個有分布式JAVA對象，封裝了數據和行為。例如，你發送了一個服務器負載的通知，里面還包含了一個顯示負載重要性的級別的機制，說白了就是對象里面有個方法，可以判定負載的嚴重程度。
      5、快速的監控解決方案。不同的開發人員只需要自己開發MBean，而不需要花很多的時間在相互的協作上面，這些MBean分布在不同的主機上，但可以通過一個管理工具就可以管理所有的這些應用。

    JMX的一些術語
    1、可管理資源（Manageable resource）
    可以是任何的應用、設備、或者其他存在的實體，能夠被java訪問和包裝。是被JMX MBean管理的資源。
    2、MBean（Managed Bean）
    是滿足某些命名規則和繼承JMX 規范的java類，為可管理資源的管理和訪問暴露接口。通過屬性和行為來暴露接口。有這3類：Standard, Dynamic, and Model MBeans。
    3、MBean Server
    管理一組MBean的JAVA類。是JMX 管理環境核心。是MBean的注冊器。
    4、JMX Agent
    JMX代理是為管理一組MBean提供一系列服務的java進程。是一個MBean Server的容器，它還提供了一些有用的服務：創建MBean之間的關系，動態加載類，簡單的監控服務，定時器服務。Agent有一個協議適配器和連接器集合能使外部程序連接到他們。
    5、Protocol adapters and connectors
    協議適配器和連接器是位于JMX Agent內部的對象。把Agent暴露給管理程序和協議。一個Agent可以有很多適配器和連接器。
    6、Management application
    連接到JMX Agent的用戶應用程序。
    7、Notification
    通知是Mbean或者Mbean server發送的java對象，他們封裝了事件、警告、或者其他的一般信息。其他的Mbean或者java對象可以注冊成為監聽器來接受通知。
    8、Instrumentation（設備化）
    用MBean暴露一個可管理資源的過程。
    
    JMX架構
    JMX架構主要分為三層：Distributed layer，Agent layer，Instrumentation layer，如下圖所示：
      

    1、Distributed layer（分布式層）
      屬于JMX架構的最外層，這層主要負責使JMX Agent能對外部程序可用。    又分為兩種：一種通過不同的協議（如SNMP，HTTP）來為MBean提供可見性。 另一種是把Agent API暴露給其他的分布式技術如RMI。
    2、The agent layer（代理層）
    它包含的最主要的組件是MBean Server，它還包括4個代理服務使管理MBean更加容易，它們分別是：    定時器（timer）、監控服務、動態MBean加載、和MBean關系服務。Agent可以和被管理的資源在同一個主機上，也可以是遠程的。
    3、The instrumentation layer
    這是最靠近資源的一層，它包含了注冊在Agent里面的MBean。
    4、Notifications
    除了架構中的三層以外，JMX提供了一個通知機制，類似于JAVA事件模型。通知機制是管理系統的最后必須的組件。Agent和MBean可以使用通知機制來發送警告或信息給管理應用。
    以上就是JMX架構的主要內容，下一篇構建一個HelloWorld的JMX程序。

    這本書的前面三章主要講了一下基本概念，客戶端程序，和Amazon的S3，這篇博客總結一下第四章，個人感覺有很多重要的概念。
    面向資源的架構（The Resource-Oriented Architecture），這里的資源必須要有一個URI，資源和URI的關系：一個資源可能有一個或多個URI，而一個URI只能指定一個資源。

    Restful WS的特性：
    1、可尋址性（Addressability）
        資源通過URI來暴露給用戶，可尋址性是最基本的特性。由于可尋址性，你可以把URI保存在你的書簽里，你可以把鏈接發給別人，而不用把Html文件下載下來發給別人，也可以通過URI對資源進行緩存。

    2、無狀態性（Statelessness）
        無狀態性意味著每個HTTP請求是完全隔離的。每次客戶端發送請求都必須帶上所有服務器端需要的信息。    
        無狀態的應用更容易分布到有負責均衡的多臺服務器上；無狀態性也更容易緩存：緩存工具只需要看這一個請求，和任何其他請求無關。
        應用狀態和資源狀態（Application State Versus Resource State）
        應用狀態位于客戶端，而資源狀態位于服務器端，對于客戶端，每個客戶端都有各自的應用狀態，例如：在google搜索，你可能搜索某個單詞且當前頁是第3頁，我可能搜索另一個單詞且在第一頁，所以每個客戶端都有一個應用狀態。當客戶端發起請求的時候，必須告訴服務器你的應用狀態，比如你當前要看某個單詞搜索結果的第幾頁，服務器端返回結果上有其他鏈接，這些鏈接客戶端可能作為未來的請求。
        而對于資源狀態，對于每個客戶端都是相同的，就是服務器上的資源。  
  
    3、表述性（Representations）
        表述性，就是資源的表現形式，相同的資源可以有不同的表述性，比如同一個bug列表可以用XML文檔表示，也可以用文本方式表示等等。對于同一資源的不同的Representation，如何知道客戶端請求哪一種呢？作者建議不同的Representation使用不同的URI。

    4、連通性（Links and Connectedness）
        簡單點說，就是返回的結果中有對其他資源的鏈接（URI），比如google搜索，搜索結果可能有其他頁的鏈接。

    5、統一的接口（The Uniform Interface）
        也就是說Restful WS使用HTTP的基本方法作為他的方法的表示，主要使用HTTP的四個方法：GET,PUT,DELETE,POST。HEAD和OPTIONS用的比較少。
        取得某個資源的表述的時候使用GET。
        創建一個新的資源的時候，PUT到一個新的URI，或者POST到一個已經存在的URI。
        修改資源，使用PUT到存在的URI。
        刪除資源使用DELETE。
        PUT和POST都可以創建新的資源，那有什么區別呢？POST可以創建從屬資源，如一個webblog程序通過資源（/weblogs/myweblog）暴露每個blog，而某個blog下面的條目作為從屬資源為/weblogs/myweblog/entries/1，當你需要增加一個條目的時候，你可以POST到父資源/weblogs/myweblog，同樣PUT也可以完成這個工作，在這里POST和PUT的區別是：當客戶端可以控制新資源的URI的時候，則使用PUT，比如blog的下面的某篇文章使用名字來訪問，如/weblogs/myweblog/entries/restful_ws_1（這樣某個博客下面的文章不能重復），則當你發表一篇新文章的時候，可以PUT到新的URI如/weblogs/myweblog/entries/restful_ws_2來創建資源。而如果客戶端不能控制URI的時候，比如blog是通過服務器端某個序列號來訪問，客戶端是無法知道下一個序號是什么，這時只能使用POST，這種POST如果創建成功，則返回201，響應頭中的Location可以保護新創建資源的URI。
        還有一個區別，POST對某個存在的資源更新時，一般是追加（append），比如說對某個日志文件做POST，則把日志追加到原日志的后面。如果是PUT則進行的是替換，所以PUT是等冪的，而POST不是（后面會講）。

        安全（Safety）
        GET和HEAD方法只是獲取資源的表述，所以是安全的。當然也可能有一些副作用，比如有些服務端會記錄GET的次數等。

        等冪性（Idempotence）
        等冪性簡單點說就是一次請求和多次請求，資源的狀態是一樣。比如GET和HEAD，不論你請求多少次，資源還是在那里。請注意，DELETE和PUT也是等冪的，以為對同一個資源刪除一次或者多次，結果是一樣的，就是資源被刪除了，不存在了。為什么說PUT也是等冪的？當你PUT一個新資源的時候，資源被創建，再次PUT這個URI的時候，資源還是沒變。當你PUT一個存在的資源時，更新了資源，再次PUT的時候，還是更新成這個樣子。在PUT更新的時候，不能做相對的更新（依賴資源現在的狀態），比如每次對一個數加1，這樣資源狀態就會變化。應該每次更新成某個數，比如把某個數變成4，則無論多少次PUT，值都是4，這樣就是等冪了。
        我們設計Restful WS的時候，GET，HEAD, PUT, DELETE一定要設計成等冪的。由于網絡是不可靠的，安全性和等冪性就顯得特別重要。如果一次請求，服務器收到處理以后，客戶端沒有收到相應，客戶端會再次請求，如果沒有等冪性保障，就會發生意想不到的問題。
        POST是不安全也不等冪的，還是拿weblog的例子，如果兩次POST相同的博文，則會產生兩個資源，URI可能是這樣/weblogs/myweblog/entries/1和/weblogs/myweblog/entries/2，盡管他們的內容是一摸一樣的。
        
    

    雙親委派模型
    Java從1.2開始引入雙親委派模型。除了啟動類裝載器，每個類裝載器都有一個雙親。當類裝載器裝載某個類的時候，首先會委派它的雙親去裝載這個類，它的雙再委派自己的雙親，直到啟動類裝載器。
    Java類裝載器的結構如下：
     

    1、啟動類裝載器
    主要負責裝載jdk_home/lib目錄下的核心api  或 -Xbootclasspath 選項指定的jar包。處于雙親委派的最頂層，該類其實是由C語言編寫。
    2、擴展類裝載器
    主要負責裝載jdk_home/lib/ext目錄下的jar包或 -Djava.ext.dirs 指定目錄下的jar包
    3、系統類裝載器
    主要負責裝載ClassPath下的類。
    4、自定義類裝載器
    自定義類繼承ClassLoader或其子類。可以運行時動態裝載某些類。
    
    


    
   
   

其實網上已經有很多java Class文件的解析實例的文章，寫這篇博客，只是為了自己仔仔細細的按照jvm spec看一邊，別無其他。

先上class文件的格式。

其中，u2代表2個字節的無符號整數。u4代表4個字節的無符號整數，其他如cp_info、field_info
是一些結構數據，接下去會講。
這次要解析的是一個非常簡單的類：TJ.java，代碼如下：

使用jdk1.6編譯，產生的二進制類文件如下：

下面對照上面的格式結構一點點的解析。

CA FE BA BE：頭四個字節是魔數，表示這是java class文件。

00 00：次版本為0。

00 32：主版本0x32，表示jdk1.6編譯的。Jdk1.5為0x31，jdk1.4為0x30。

00 16：常量池的入口（entry）數量。包括自己本身（這里很奇怪），所以接下來有21項的常量池入口。


我會在每個常量池項的前面表上索引。常量池的第一個字節表示類型。具體類型對照表如下：

Constant Type	Value
CONSTANT_Class	7
CONSTANT_Fieldref	9
CONSTANT_Methodref	10
CONSTANT_InterfaceMethodref	11
CONSTANT_String	8
CONSTANT_Integer	3
CONSTANT_Float	4
CONSTANT_Long	5
CONSTANT_Double	6
CONSTANT_NameAndType	12
CONSTANT_Utf8	1

0A 00 04 00 12：【1】，第一個字節為10，所以是CONSTANT_Methodref，它的結構如下：

CONSTANT_Methodref_info {



u1 tag;



u2 class_index;



u2 name_and_type_index;



}



所以，class_index=4，name_and_type_index=12,這兩個代表常量池第4項和第12項。



09 00 03 00 13：【2】 這是一個CONSTANT_Fieldref，他的結構和上面的類似class_index=3，name_and_type_index=13



07 00 14：【3】這個是CONSTANT_Class，它的結構如下：



CONSTANT_Class_info {



     u1 tag;



     u2 name_index;



    }



name_index為20，指向的是一個utf8的字節碼，即TJ，這個后面會看到。



07 00 15: 【4】 也是一個CONSTANT_Class，name_index為21，即java/lang/Object



01 00 02 66 31: 【5】CONSTANT_Utf8，結構如下：



CONSTANT_Utf8_info {



u1 tag;



u2 length;



u1 bytes[length];



}



最后兩個字節代表字符串“f1”的utf-8字節碼。



01 00 01 49：【6】字符串I



01 00 0D 43 6F 6E 73 74 61 6E 74 56 61 6C 75 65 ：【7】字符串ConstantValue



03 00 00 00 02：【8】CONSTANT_Integer，整數值2 



01 00 06 3C 69 6E 69 74 3E：【9】字符串<init>



01 00 03 28 29 56：【10】字符串()V



01 00 04 43 6F 64 65：【11】字符串code



01 00 0F 4C 69 6E 65 4E 75 6D 62 65 72 54 61 62 6C 65：【12】字符串LineNumberTable



01 00 02 6D 31：【13】字符串m1



01 00 04 28 49 29 49 ：【14】字符串(I)I，表示一個整數參數且返回整數的方法。



01 00 02 6D 32 ：【15】字符串m2



01 00 0A 53 6F 75 72 63 65 46 69 6C 65 ：【16】字符串SourceFile



01 00 07 54 4A 2E 6A 61 76 61：【17】字符串TJ.java



0C 00 09 00 0A：【18】CONSTANT_NameAndType，結構如下：



CONSTANT_NameAndType_info {



u1 tag;



u2 name_index;



u2 descriptor_index;



}

name_index=9，代表方法<init>，descriptor_index=10，()V，代表無參且返回void的方法。





0C 00 05 00 06：【19】結構同上，name_index=5，即f1，descriptor_index=6，即整數。



01 00 02 54 4A ：【20】字符串TJ



01 00 10 6A 61 76 61 2F 6C 61 6E 67 2F 4F 62 6A 65 63 74：【21】字符串java/lang/Object

到此，常量池結束。
00 21：類的描述符為public。
00 03 ：this class為常量池第三個，TJ，即這個類的名字為TJ
00 04：super class為常量池第四個，java/lang/Object，即它的超類為java.lang.Object
00 00：接口個數0。
00 01：field數量1。
00 12 00 05 00 06 00 01 00 07 00 00 00 02 00 08：field的結構如下
field_info {
     u2 access_flags;
     u2 name_index;
     u2 descriptor_index;
     u2 attributes_count;
     attribute_info attributes[attributes_count];
    }
access_flags為00 12，代表ACC_PRIVATE+ ACC_FINAL

name_index：常量池索引為5的入口，即f1，即類成員的名字為f1
descriptor_index：I，代表integer。
 attributes_count：1個。
attribute_info：
attribute_info {
     u2 attribute_name_index;
     u4 attribute_length;
     u1 info[attribute_length];
}

attribute_name_index：7，即ConstantValue，結構如下
ConstantValue_attribute {
     u2 attribute_name_index;
     u4 attribute_length;
     u2 constantvalue_index;
    }
attribute_length：2
constantvalue_index：2
----------------------------------------下面開始方法

00 03：3個方法。
method_info {
     u2 access_flags;
     u2 name_index;
     u2 descriptor_index;
     u2 attributes_count;
     attribute_info attributes[attributes_count];
    }
--------------------------------------------第一個方法<init>，這個是編譯器產生的生成實例的初始化方法。
access_flags：public
name_index：00 09，<init>
descriptor_index：00 0A，()V表示無參數，返回void
attributes_count :00 01,1個
attribute_name_index ：00 0B ，code
attribute_length：38個
Code_attribute {
     u2 attribute_name_index;
     u4 attribute_length;
     u2 max_stack;
     u2 max_locals;
     u4 code_length;
     u1 code[code_length];
     u2 exception_table_length;
     {     u2 start_pc;
            u2 end_pc;
            u2  handler_pc;
            u2  catch_type;
     } exception_table[exception_table_length];
     u2 attributes_count;
     attribute_info attributes[attributes_count];
    }
max_stack: 00 02
max_locals: 00 01
code_length: 00 00 00 0A,10
code: 2A B7 00 01 2A 05 B5 00 02 B1,指令
exception table length：00 00
attributes_count：1
attribute_name_index：00 0C，LineNumberTable
LineNumberTable_attribute {
     u2 attribute_name_index;
     u4 attribute_length;
     u2 line_number_table_length;
     {  u2 start_pc;     
        u2 line_number;     
     } line_number_table[line_number_table_length];
    }
attribute_length：10
line_number_table_length：2
start_pc：00 00
line_number：00 01
tart_pc：00 04
line_number：00 03
到此第一個方法結束。
----------------------------------------------------------------------第二個方法開始
access_flags：00 01，public
name_index：00 0D，m1
desc_index：00 0E，(I)I，有一個整數參數，返回一個整數。
00 01：一個attr
00 0B：code
00 00 00 1C：attr_length:28
Code_atrr:28個字節，不分析了和上面的方法相同。

----------------------------------------------------------------------第三個方法
00 02：private
00 0F：m2
00 0A: ()V，無參，返回void
00 01：一個attr
00 0B：code
00 00 00 19：attr_length  25
接下去的25個字節是Code_atrr，同樣不分析了。
------------------------------------------------------------------
00 01：1個類的attr
00 10：SourceFile
00 00 00 02：len=2
00 11：17，TJ.java

    搞了那么多年的程序，一直也沒去搞明白URI和URL的區別，總感覺這兩個東東差不多。看了《OReilly HTTP The Definitive Guide》，總結一下：

   從字面上理解，URI強調的是“資源”，而URL強調的是“定位”.URI更為注重資源而不太注重位置,URI對于定位Internet上的資源是更為通用的架構。

   URI有兩種形式：一種是URL，另一種是URN。

   URL表示的是某臺特定主機上的一個資源的具體路徑，是一個精確的、固定的位置。

    URN（uniform resource name）指的是某一塊特定內容的唯一的名字，和資源所在的位置無關，是location-independent的，允許資源從一個地方移到另一個地方。

    URN仍然是實驗性的，還沒有被廣泛的采用。URN需要一個基礎架構來支持解決資源定位問題。

    所以說，現在URI基本上都是URL。