工廠方法模式：
一個(gè)抽象產(chǎn)品類，可以派生出多個(gè)具體產(chǎn)品類。   
一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類。   
每個(gè)具體工廠類只能創(chuàng)建一個(gè)具體產(chǎn)品類的實(shí)例。

抽象工廠模式：
多個(gè)抽象產(chǎn)品類，每個(gè)抽象產(chǎn)品類可以派生出多個(gè)具體產(chǎn)品類。   
一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類。   
每個(gè)具體工廠類可以創(chuàng)建多個(gè)具體產(chǎn)品類的實(shí)例。   
    
區(qū)別：
工廠方法模式只有一個(gè)抽象產(chǎn)品類，而抽象工廠模式有多個(gè)。   
工廠方法模式的具體工廠類只能創(chuàng)建一個(gè)具體產(chǎn)品類的實(shí)例，而抽象工廠模式可以創(chuàng)建多個(gè)。



工廠方法模式： 一個(gè)抽象產(chǎn)品類，可以派生出多個(gè)具體產(chǎn)品類。 一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類。 每個(gè)具體工廠類只能創(chuàng)建一個(gè)具體產(chǎn)品類的實(shí)例。 抽象工廠模式： 多個(gè)抽象產(chǎn)品類，每個(gè)抽象產(chǎn)品類可以派生出多個(gè)具體產(chǎn)品類。 一個(gè)抽象工廠類，可以派生出多個(gè)具體工廠類。 每個(gè)具體工廠類可以創(chuàng)建多個(gè)具體產(chǎn)品類的實(shí)例。 區(qū)別： 工廠方法模式只有一個(gè)抽象產(chǎn)品類，而抽象工廠模式有多個(gè)。 工廠方法模式的具體工廠類只能創(chuàng)建一個(gè)具體產(chǎn)品類的實(shí)例，而抽象工廠模式可以創(chuàng)建多個(gè)。


GOF《設(shè)計(jì)模式》寫(xiě)的很清楚，工廠方法是由子類自行決定實(shí)例化那個(gè)類，而抽象工廠是自己決定實(shí)例化哪個(gè)類。至于是組合還是繼承還是實(shí)現(xiàn)接口都無(wú)所謂。根本區(qū)別在于是自己實(shí)例化還是子類實(shí)例化。

    哈希（hash）是一種非?？斓牟檎曳椒ǎ话闱闆r下查找的時(shí)間復(fù)雜度為O（1）。常用于連接（join）操作，如SQL Server和Oracle中的哈希連接（hash join）。但是SQL Server和Oracle等常見(jiàn)的數(shù)據(jù)庫(kù)并不支持哈希索引（hash index）。MySQL的Heap存儲(chǔ)引擎默認(rèn)的索引類型為哈希，而InnoDB存儲(chǔ)引擎提出了另一種實(shí)現(xiàn)方法，自適應(yīng)哈希索引（adaptive hash index）。

InnoDB存儲(chǔ)引擎會(huì)監(jiān)控對(duì)表上索引的查找，如果觀察到建立哈希索引可以帶來(lái)速度的提升，則建立哈希索引，所以稱之為自適應(yīng)（adaptive）的。自適應(yīng)哈希索引通過(guò)緩沖池的B+樹(shù)構(gòu)造而來(lái)，因此建立的速度很快。而且不需要將整個(gè)表都建哈希索引，InnoDB存儲(chǔ)引擎會(huì)自動(dòng)根據(jù)訪問(wèn)的頻率和模式來(lái)為某些頁(yè)建立哈希索引。

根據(jù)InnoDB的官方文檔顯示，啟用自適應(yīng)哈希索引后，讀取和寫(xiě)入速度可以提高2倍；對(duì)于輔助索引的連接操作，性能可以提高5倍。在我看來(lái)，自適應(yīng)哈希索引是非常好的優(yōu)化模式，其設(shè)計(jì)思想是數(shù)據(jù)庫(kù)自優(yōu)化（self-tuning），即無(wú)需DBA對(duì)數(shù)據(jù)庫(kù)進(jìn)行調(diào)整。

通過(guò)命令SHOW ENGINE INNODB STATUS可以看到當(dāng)前自適應(yīng)哈希索引的使用狀況，如下所示：

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. ...... 

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

由于自適應(yīng)哈希索引是由InnoDB存儲(chǔ)引擎控制的，所以這里的信息只供我們參考。不過(guò)我們可以通過(guò)參數(shù)innodb_adaptive_hash_index來(lái)禁用或啟動(dòng)此特性，默認(rèn)為開(kāi)啟。

轉(zhuǎn)自http://www.cnblogs.com/ylqmf/archive/2011/09/16/2179166.html

通過(guò)什么方法來(lái)排查是否linux服務(wù)器的負(fù)載過(guò)大？

通過(guò)top命令來(lái)查看服務(wù)器負(fù)載

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

     一個(gè)單核的處理器可以形象得比喻成一條單車道。如果前面沒(méi)有車輛在等待，那么你可以告訴后面的司機(jī)通過(guò)。如果車輛眾多，那么需要告知他們可能需要稍等一會(huì)。

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

    上面的情況和處理器的負(fù)載情況非常相似。一輛汽車的過(guò)橋時(shí)間就好比是處理器處理某線程的實(shí)際時(shí)間。Unix 系統(tǒng)定義的進(jìn)程運(yùn)行時(shí)長(zhǎng)為所有處理器內(nèi)核的處理時(shí)間加上線程在隊(duì)列中等待的時(shí)間。

    和收過(guò)橋費(fèi)的管理員一樣，你當(dāng)然希望你的汽車（操作）不會(huì)被焦急的等待。所以，理想狀態(tài)下，都希望負(fù)載平均值小于1.00 。當(dāng)然不排除部分峰值會(huì)超過(guò)1.00，但長(zhǎng)此以往保持這個(gè)狀態(tài)，就說(shuō)明會(huì)有問(wèn)題，這時(shí)候你應(yīng)該會(huì)很焦急。

      “所以你說(shuō)的理想負(fù)荷為1.00 ？”

    嗯，這種情況其實(shí)并不完全正確。負(fù)荷1.00 說(shuō)明系統(tǒng)已經(jīng)沒(méi)有剩余的資源了。在實(shí)際情況中，有經(jīng)驗(yàn)的系統(tǒng)管理員都會(huì)將這條線劃在0.70：

      “需要進(jìn)行調(diào)查法則”：如果長(zhǎng)期你的系統(tǒng)負(fù)載在0.70 上下，那么你需要在事情變得更糟糕之前，花些時(shí)間了解其原因。

      “現(xiàn)在就要修復(fù)法則”：1.00 。如果你的服務(wù)器系統(tǒng)負(fù)載長(zhǎng)期徘徊于1.00，那么就應(yīng)該馬上解決這個(gè)問(wèn)題。否則，你將半夜接到你上司的電話，這可不是件令人愉快的事情。

      “凌晨三點(diǎn)半鍛煉身體法則”：5.00。如果你的服務(wù)器負(fù)載超過(guò)了5.00 這個(gè)數(shù)字，那么你將失去你的睡眠，還得在會(huì)議中說(shuō)明這情況發(fā)生的原因，總之千萬(wàn)不要讓它發(fā)生。

    那么多個(gè)處理器呢？我的均值是3.00，但是系統(tǒng)運(yùn)行正常！哇喔，你有四個(gè)處理器的主機(jī)？那么它的負(fù)載均值在3.00 是很正常的。在多處理器系統(tǒng)中，負(fù)載均值是基于內(nèi)核的數(shù)量決定的。以100% 負(fù)載計(jì)算，1.00 表示單個(gè)處理器，而2.00 則說(shuō)明有兩個(gè)雙處理器，那么4.00 就說(shuō)明主機(jī)具有四個(gè)處理器。

　　回到我們上面有關(guān)車輛過(guò)橋的比喻。1.00 我說(shuō)過(guò)是“一條單車道的道路”。那么在單車道1.00 情況中，說(shuō)明這橋梁已經(jīng)被車塞滿了。而在雙處理器系統(tǒng)中，這意味著多出了一倍的負(fù)載，也就是說(shuō)還有50% 的剩余系統(tǒng)資源- 因?yàn)檫€有另外條車道可以通行。

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

 

從上圖的top命令可以了解到，Linux服務(wù)器運(yùn)行了5天23小時(shí)20分，在load average的數(shù)據(jù)來(lái)看，這臺(tái)快吧Linux無(wú)盤(pán)服務(wù)器可以說(shuō)是壓力為零，運(yùn)行十分流暢。 

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

說(shuō)明：%util:一秒中有百分之多少的時(shí)間用于I/O操作，或者說(shuō)一秒中有多少時(shí)間I/O隊(duì)列是非空的。
即delta(use)/s/1000 (因?yàn)閡se的單位為毫秒)
如果%util接近100%，說(shuō)明產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤(pán)可能存在瓶頸。

方法三：

如果玩游戲很卡，可以用hdparm –t /dev/磁盤(pán)名稱來(lái)測(cè)試磁盤(pán)性能是否達(dá)標(biāo)，下圖是單個(gè)希捷1T的盤(pán)測(cè)試的結(jié)果說(shuō)明：sd表示硬盤(pán)是SATA，SCSI或者SAS，a表示串口的第一塊硬盤(pán)

 本文轉(zhuǎn)摘自：http://www.flybaaa.com/help/69_1.html

 

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

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

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

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

邏輯CPU的個(gè)數(shù)如下：

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

按理說(shuō)物理CPU個(gè)數(shù)×核數(shù)就應(yīng)該等于邏輯CPU的

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

JVM在裝載class文件的時(shí)候，會(huì)有一步是將符號(hào)引用解析為直接引用的過(guò)程。

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

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

指向?qū)嵗兞?、?shí)例方法的直接引用都是偏移量。實(shí)例變量的直接引用可能是從對(duì)象的映像開(kāi)始算起到這個(gè)實(shí)例變量位置的偏移量。實(shí)例方法的直接引用可能是方法表的偏移量。

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

書(shū)中第199頁(yè)說(shuō)，通過(guò)“接口引用”來(lái)調(diào)用一個(gè)方法，jvm必須搜索對(duì)象的類的方法表才能找到一個(gè)合適的方法。這是因?yàn)?span style="background-color: #ffccff;">實(shí)現(xiàn)同一個(gè)接口的這些類中，不一定所有的接口中的方法在類方法區(qū)中的偏移量都是一樣的。他們有可能會(huì)不一樣。這樣的話可能就要搜索方法表才能確認(rèn)要調(diào)用的方法在哪里。

而通過(guò)“類引用”來(lái)調(diào)用一個(gè)方法的時(shí)候，直接通過(guò)偏移量就可以找到要調(diào)用的方法的位置了。【因?yàn)樽宇愔械姆椒ǖ钠屏扛割愔械钠屏渴且恢碌摹?/span>

所以，通過(guò)接口引用調(diào)用方法會(huì)比類引用慢一些。

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

interface A{void say();}

class B implements A{}

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

在上面的第三行代碼中，就是用“接口引用”來(lái)調(diào)用方法。

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

符號(hào)引用：

符號(hào)引用是一個(gè)字符串，它給出了被引用的內(nèi)容的名字并且可能會(huì)包含一些其他關(guān)于這個(gè)被引用項(xiàng)的信息——這些信息必須足以唯一的識(shí)別一個(gè)類、字段、方法。這樣，對(duì)于其他類的符號(hào)引用必須給出類的全名。對(duì)于其他類的字段，必須給出類名、字段名以及字段描述符。對(duì)于其他類的方法的引用必須給出類名、方法名以及方法的描述符。

總結(jié)：JVM對(duì)于直接引用和符號(hào)引用的處理是有區(qū)別的，可以看到符號(hào)引用時(shí)，JVM將使用StringBuilder來(lái)完成字符串的  添加，而直接引用時(shí)則直接使用String來(lái)完成;直接引用永遠(yuǎn)比符號(hào)引用效率更快，但實(shí)際應(yīng)用開(kāi)發(fā)中不可能全用直接引用，要提高效能可以考慮按虛擬機(jī)的思維來(lái)編寫(xiě)你的程序。

1.0 直接引用：

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

反編譯后的：

F:\java\res\字節(jié)碼>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 符號(hào)引用：

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

反編譯后的：

F:\java\res\字節(jié)碼>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.

  對(duì)于如何達(dá)到“無(wú)碎片”的目的，理解上可能有些困難，下面我把新生代回收機(jī)制詳細(xì)解釋一下：

  注意，兩個(gè)survivor是交替使用的，在任意一個(gè)時(shí)刻，必定有一個(gè)survivor為空，一個(gè)survivor中存放著對(duì)象（連續(xù)存放，無(wú)碎片）?；厥者^(guò)程如下：

  S1、GC，將eden中的live對(duì)象放入當(dāng)前不為空的survivor中，將eden中的非live對(duì)象回收。如果survivor滿了，下次回收?qǐng)?zhí)行S2；如果survivor未滿，下次回收仍然以S1的方式回收；

  S2、GC，將eden和存放著對(duì)象的survivor中的live對(duì)象放入當(dāng)前為空的survivor中，將非live對(duì)象回收。

  可以看到，上述的新生代回收機(jī)制保證了一個(gè)survivor為空，另一個(gè)非空survivor中無(wú)碎片。

  在執(zhí)行一定次數(shù)的minor GC后，會(huì)通過(guò)Full GC將新生代的survivor中的對(duì)象移入老年代。

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

tcpdump抓包并保存成cap文件

tcpdump 的抓包保存到文件的命令參數(shù)是-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大小分割保存文件， 超過(guò)100m另開(kāi)一個(gè)文件 -C 100m 
抓10000個(gè)包后退出 -c 10000 
后臺(tái)抓包， 控制臺(tái)退出也不會(huì)影響： 
nohup tcpdump -i eth1 port 110 -w /tmp/xxx.cap & 
抓下來(lái)的文件可以直接用ethereal 或者wireshark打開(kāi)。 wireshark就是新版的ethereal，程序換名了

轉(zhuǎn)載自：

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