工廠方法模式：
一個抽象產品類，可以派生出多個具體產品類。   
一個抽象工廠類，可以派生出多個具體工廠類。   
每個具體工廠類只能創建一個具體產品類的實例。

抽象工廠模式：
多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。   
一個抽象工廠類，可以派生出多個具體工廠類。   
每個具體工廠類可以創建多個具體產品類的實例。   
    
區別：
工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。   
工廠方法模式的具體工廠類只能創建一個具體產品類的實例，而抽象工廠模式可以創建多個。



工廠方法模式： 一個抽象產品類，可以派生出多個具體產品類。 一個抽象工廠類，可以派生出多個具體工廠類。 每個具體工廠類只能創建一個具體產品類的實例。 抽象工廠模式： 多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。 一個抽象工廠類，可以派生出多個具體工廠類。 每個具體工廠類可以創建多個具體產品類的實例。 區別： 工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。 工廠方法模式的具體工廠類只能創建一個具體產品類的實例，而抽象工廠模式可以創建多個。


GOF《設計模式》寫的很清楚，工廠方法是由子類自行決定實例化那個類，而抽象工廠是自己決定實例化哪個類。至于是組合還是繼承還是實現接口都無所謂。根本區別在于是自己實例化還是子類實例化。

    哈希（hash）是一種非?？斓牟檎曳椒?，一般情況下查找的時間復雜度為O（1）。常用于連接（join）操作，如SQL Server和Oracle中的哈希連接（hash join）。但是SQL Server和Oracle等常見的數據庫并不支持哈希索引（hash index）。MySQL的Heap存儲引擎默認的索引類型為哈希，而InnoDB存儲引擎提出了另一種實現方法，自適應哈希索引（adaptive hash index）。

InnoDB存儲引擎會監控對表上索引的查找，如果觀察到建立哈希索引可以帶來速度的提升，則建立哈希索引，所以稱之為自適應（adaptive）的。自適應哈希索引通過緩沖池的B+樹構造而來，因此建立的速度很快。而且不需要將整個表都建哈希索引，InnoDB存儲引擎會自動根據訪問的頻率和模式來為某些頁建立哈希索引。

根據InnoDB的官方文檔顯示，啟用自適應哈希索引后，讀取和寫入速度可以提高2倍；對于輔助索引的連接操作，性能可以提高5倍。在我看來，自適應哈希索引是非常好的優化模式，其設計思想是數據庫自優化（self-tuning），即無需DBA對數據庫進行調整。

通過命令SHOW ENGINE INNODB STATUS可以看到當前自適應哈希索引的使用狀況，如下所示：

1. mysql> show engine innodb status\G;  
2. *************************** 1. row ***************************  
3. Status:   
4. =====================================  
5. 090922 11:52:51 INNODB MONITOR OUTPUT 
6. =====================================  
7. Per second averages calculated from the last 15 seconds  
8. ......  
9. -------------------------------------  
10. INSERT BUFFER AND ADAPTIVE HASH INDEX  
11. -------------------------------------  
12. Ibuf: size 2249, free list len 3346, seg size 5596,  
13. 374650 inserts, 51897 merged recs, 14300 merges  
14. Hash table size 4980499, node heap has 1246 buffer(s)  
15. 1640.60 hash searches/s, 3709.46 non-hash searches/s  
16. ...... 

現在可以看到自適應哈希索引的使用信息了，包括自適應哈希索引的大小、使用情況、每秒使用自適應哈希索引搜索的情況。值得注意的是，哈希索引只能用來搜索等值的查詢，如select * from table where index_col = 'xxx'，而對于其他查找類型，如范圍查找，是不能使用的。因此，這里出現了non-hash searches/s的情況。用hash searches : non-hash searches命令可以大概了解使用哈希索引后的效率。

由于自適應哈希索引是由InnoDB存儲引擎控制的，所以這里的信息只供我們參考。不過我們可以通過參數innodb_adaptive_hash_index來禁用或啟動此特性，默認為開啟。

轉自http://www.cnblogs.com/ylqmf/archive/2011/09/16/2179166.html

通過什么方法來排查是否linux服務器的負載過大？

通過top命令來查看服務器負載

 再對此Linux服務器性能分析之前，先了解下Linux系統Load average負載的知識，負載均值在uptime 或者top 命令中可以看到，它們可能會顯示成這個樣子：load average: 0.15, 0.14, 0.11
很多人會這樣理解負載均值：三個數分別代表不同時間段的系統平均負載（一分鐘、五分鐘、以及十五分鐘），它們的數字當然是越小越好。數字越高，說明服務器的負載越大,這也可能是服務器出現某種問題的信號。

     一個單核的處理器可以形象得比喻成一條單車道。如果前面沒有車輛在等待，那么你可以告訴后面的司機通過。如果車輛眾多，那么需要告知他們可能需要稍等一會。

因此，需要些特定的代號表示目前的車流情況，例如：
　　0.00 表示目前橋面上沒有任何的車流。實際上這種情況與0.00 和1.00 之間是相同的，總而言之很通暢，過往的車輛可以絲毫不用等待的通過。
　　1.00 表示剛好是在這座橋的承受范圍內。這種情況不算糟糕，只是車流會有些堵，不過這種情況可能會造成交通越來越慢。
　　超過1.00，那么說明這座橋已經超出負荷，交通嚴重的擁堵。那么情況有多糟糕？例如2.00 的情況說明車流已經超出了橋所能承受的一倍，那么將有多余過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了，說明這座橋基本上已經快承受不了，還有超出橋負載兩倍多的車輛正在等待。

    上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程的實際時間。Unix 系統定義的進程運行時長為所有處理器內核的處理時間加上線程在隊列中等待的時間。

    和收過橋費的管理員一樣，你當然希望你的汽車（操作）不會被焦急的等待。所以，理想狀態下，都希望負載平均值小于1.00 。當然不排除部分峰值會超過1.00，但長此以往保持這個狀態，就說明會有問題，這時候你應該會很焦急。

      “所以你說的理想負荷為1.00 ？”

    嗯，這種情況其實并不完全正確。負荷1.00 說明系統已經沒有剩余的資源了。在實際情況中，有經驗的系統管理員都會將這條線劃在0.70：

      “需要進行調查法則”：如果長期你的系統負載在0.70 上下，那么你需要在事情變得更糟糕之前，花些時間了解其原因。

      “現在就要修復法則”：1.00 。如果你的服務器系統負載長期徘徊于1.00，那么就應該馬上解決這個問題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。

      “凌晨三點半鍛煉身體法則”：5.00。如果你的服務器負載超過了5.00 這個數字，那么你將失去你的睡眠，還得在會議中說明這情況發生的原因，總之千萬不要讓它發生。

    那么多個處理器呢？我的均值是3.00，但是系統運行正常！哇喔，你有四個處理器的主機？那么它的負載均值在3.00 是很正常的。在多處理器系統中，負載均值是基于內核的數量決定的。以100% 負載計算，1.00 表示單個處理器，而2.00 則說明有兩個雙處理器，那么4.00 就說明主機具有四個處理器。

　　回到我們上面有關車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那么在單車道1.00 情況中，說明這橋梁已經被車塞滿了。而在雙處理器系統中，這意味著多出了一倍的負載，也就是說還有50% 的剩余系統資源- 因為還有另外條車道可以通行。

所以，單處理器已經在負載的情況下，雙處理器的負載滿額的情況是2.00，它還有一倍的資源可以利用。

 

從上圖的top命令可以了解到，Linux服務器運行了5天23小時20分，在load average的數據來看，這臺快吧Linux無盤服務器可以說是壓力為零，運行十分流暢。 

方法二：輸入iostat -x -k -t 

說明：%util:一秒中有百分之多少的時間用于I/O操作，或者說一秒中有多少時間I/O隊列是非空的。
即delta(use)/s/1000 (因為use的單位為毫秒)
如果%util接近100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。

方法三：

如果玩游戲很卡，可以用hdparm –t /dev/磁盤名稱來測試磁盤性能是否達標，下圖是單個希捷1T的盤測試的結果說明：sd表示硬盤是SATA，SCSI或者SAS，a表示串口的第一塊硬盤

 本文轉摘自：http://www.flybaaa.com/help/69_1.html

 

一直以來以為通過top然后按數字1鍵，查到的cpu個數是服務器的物理cpu個數，今天在看服務器的硬件配置清單中發現一服務器的物理cpu個數是4個，我就奇怪了，這臺機子我的影響很深，明明是48啊，當時通過top 1查看cpu信息還提示 “Sorry ,terminal is not big enough”。想當初服務器只能識別到32個。還是重新編譯內核搞定的。后來經過查詢原來不是這樣滴，top 1查看的是邏輯cpu個數，一下為記。
查看Linux服務器的CPU詳細情況
判斷Linux服務器CPU情況的依據如下：
具有相同core id的CPU是同一個core的超線程。(Any cpu with the same core id are hyperthreads in the same core.)
具有相同physical id的CPU是同一個CPU封裝的線程或核心。(Any cpu with the same physical id are threads or cores in the same physical socket.)
下面舉例說明。
物理CPU個數如下：

[root@dbabc.net ～］# cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l 4

每個物理CPU中core的個數(即核數)如下：

[root@dbabc.net ～］# cat /proc/cpuinfo| grep "cpu cores"| uniq cpu cores       : 12

邏輯CPU的個數如下：

［root@dbabc.net ～］#cat /proc/cpuinfo| grep "processor"| wc -l 48

按理說物理CPU個數×核數就應該等于邏輯CPU的

Dbabc.Net [http://dbabc.net]
本文鏈接：http://dbabc.net/archives/2012/02/13/linux-cpu-info-count.shtml

JVM在裝載class文件的時候，會有一步是將符號引用解析為直接引用的過程。

那么這里的直接引用到底是什么呢？

對于指向“類型”【Class對象】、類變量、類方法的直接引用可能是指向方法區的本地指針。

指向實例變量、實例方法的直接引用都是偏移量。實例變量的直接引用可能是從對象的映像開始算起到這個實例變量位置的偏移量。實例方法的直接引用可能是方法表的偏移量。

在《深入java虛擬機》書的第197頁我們可以看到，子類中方法表的偏移量和父類中的方法表的偏移量是一致的。比如說父類中有一個say()方法的偏移量是7，那么子類中say方法的偏移量也是7。

書中第199頁說，通過“接口引用”來調用一個方法，jvm必須搜索對象的類的方法表才能找到一個合適的方法。這是因為實現同一個接口的這些類中，不一定所有的接口中的方法在類方法區中的偏移量都是一樣的。他們有可能會不一樣。這樣的話可能就要搜索方法表才能確認要調用的方法在哪里。

而通過“類引用”來調用一個方法的時候，直接通過偏移量就可以找到要調用的方法的位置了?！疽驗樽宇愔械姆椒ǖ钠屏扛割愔械钠屏渴且恢碌摹?/span>

所以，通過接口引用調用方法會比類引用慢一些。

下面介紹下什么是接口引用。

interface A{void say();}

class B implements A{}

class C{public static void main(String []s){A a=new B();a.say()}}

在上面的第三行代碼中，就是用“接口引用”來調用方法。

--------------------------------------------------------------------

符號引用：

符號引用是一個字符串，它給出了被引用的內容的名字并且可能會包含一些其他關于這個被引用項的信息——這些信息必須足以唯一的識別一個類、字段、方法。這樣，對于其他類的符號引用必須給出類的全名。對于其他類的字段，必須給出類名、字段名以及字段描述符。對于其他類的方法的引用必須給出類名、方法名以及方法的描述符。

總結：JVM對于直接引用和符號引用的處理是有區別的，可以看到符號引用時，JVM將使用StringBuilder來完成字符串的  添加，而直接引用時則直接使用String來完成;直接引用永遠比符號引用效率更快，但實際應用開發中不可能全用直接引用，要提高效能可以考慮按虛擬機的思維來編寫你的程序。

1.0 直接引用：

public class StringAndStringBuilder{
   public static void main(String[] args){    
       System.out.println ("s=" + "asdfa");
   }
}

反編譯后的：

F:\java\res\字節碼>javap -c StringAndStringBuilder
Compiled from "StringAndStringBuilder.java"
public class StringAndStringBuilder extends java.lang.Object{
public StringAndStringBuilder();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   ldc     #2; //String asdfa
   2:   astore_1
   3:   getstatic       #3; //Field java/lang/System.out:Ljava/io/PrintStream;
   6:   ldc     #4; //String s=asdfa
   8:   invokevirtual   #5; //Method java/io/PrintStream.println:(Ljava/lang/Str
ing;)V
   11:  return

}

2.0 符號引用：

public class StringAndStringBuilder{
   public static void main(String[] args){    
      String s="asdfa";
        System.out.println ("s=" + s);
   }
}

反編譯后的：

F:\java\res\字節碼>javap -c StringAndStringBuilder
Compiled from "StringAndStringBuilder.java"
public class StringAndStringBuilder extends java.lang.Object{
public StringAndStringBuilder();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   ldc     #2; //String asdfa
   2:   astore_1
   3:   getstatic       #3; //Field java/lang/System.out:Ljava/io/PrintStream;
   6:   new     #4; //class java/lang/StringBuilder
   9:   dup
   10:  invokespecial   #5; //Method java/lang/StringBuilder."<init>":()V
   13:  ldc     #6; //String s=
   15:  invokevirtual   #7; //Method java/lang/StringBuilder.append:(Ljava/lang/
String;)Ljava/lang/StringBuilder;
   18:  aload_1
   19:  invokevirtual   #7; //Method java/lang/StringBuilder.append:(Ljava/lang/
String;)Ljava/lang/StringBuilder;
   22:  invokevirtual   #8; //Method java/lang/StringBuilder.toString:()Ljava/la
ng/String;
   25:  invokevirtual   #9; //Method java/io/PrintStream.println:(Ljava/lang/Str
ing;)V
   28:  return

}

 StackOverflow上面給出的解釋是：

The reason for the HotSpot JVM's two survivor spaces is to reduce the need to deal with fragmentation. New objects are allocated in eden space. All well and good. When that's full, you need a GC, so kill stale objects and move live ones to a survivor space, where they can mature for a while before being promoted to the old generation. Still good so far. The next time we run out of eden space, though, we have a conundrum. The next GC comes along and clears out some space in both eden and our survivor space, but the spaces aren't contiguous. So is it better to

1. Try to fit the survivors from eden into the holes in the survivor space that were cleared by the GC?
2. Shift all the objects in the survivor space down to eliminate the fragmentation, and then move the survivors into it?
3. Just say "screw it, we're moving everything around anyway," and copy all of the survivors from both spaces into a completely separate space--the second survivor space--thus leaving you with a clean eden and survivor space where you can repeat the sequence on the next GC?

Sun's answer to the question is obvious.

  對于如何達到“無碎片”的目的，理解上可能有些困難，下面我把新生代回收機制詳細解釋一下：

  注意，兩個survivor是交替使用的，在任意一個時刻，必定有一個survivor為空，一個survivor中存放著對象（連續存放，無碎片）?；厥者^程如下：

  S1、GC，將eden中的live對象放入當前不為空的survivor中，將eden中的非live對象回收。如果survivor滿了，下次回收執行S2；如果survivor未滿，下次回收仍然以S1的方式回收；

  S2、GC，將eden和存放著對象的survivor中的live對象放入當前為空的survivor中，將非live對象回收。

  可以看到，上述的新生代回收機制保證了一個survivor為空，另一個非空survivor中無碎片。

  在執行一定次數的minor GC后，會通過Full GC將新生代的survivor中的對象移入老年代。

  對于理解GC的整個機制，推薦一篇非常好的文章：http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/

tcpdump抓包并保存成cap文件

tcpdump 的抓包保存到文件的命令參數是-w xxx.cap
抓eth1的包 
tcpdump -i eth1 -w /tmp/xxx.cap 
抓 192.168.1.123的包 
tcpdump -i eth1 host 192.168.1.123 -w /tmp/xxx.cap 
抓192.168.1.123的80端口的包 
tcpdump -i eth1 host 192.168.1.123 and port 80 -w /tmp/xxx.cap 
抓192.168.1.123的icmp的包 
tcpdump -i eth1 host 192.168.1.123 and icmp -w /tmp/xxx.cap 
抓192.168.1.123的80端口和110和25以外的其他端口的包 
tcpdump -i eth1 host 192.168.1.123 and ! port 80 and ! port 25 and ! port 110 -w /tmp/xxx.cap 
抓vlan 1的包 
tcpdump -i eth1 port 80 and vlan 1 -w /tmp/xxx.cap 
抓pppoe的密碼 
tcpdump -i eth1 pppoes -w /tmp/xxx.cap 
以100m大小分割保存文件， 超過100m另開一個文件 -C 100m 
抓10000個包后退出 -c 10000 
后臺抓包， 控制臺退出也不會影響： 
nohup tcpdump -i eth1 port 110 -w /tmp/xxx.cap & 
抓下來的文件可以直接用ethereal 或者wireshark打開。 wireshark就是新版的ethereal，程序換名了

轉載自：

http://blog.sina.com.cn/s/blog_4a071ed80100sv13.html