工厂方法模式：
一个抽象产品类，可以派生出多个具体产品类。   
一个抽象工厂类，可以派生出多个具体工厂类。   
每个具体工厂类只能创建一个具体产品类的实例。

抽象工厂模式：
多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。   
一个抽象工厂类，可以派生出多个具体工厂类。   
每个具体工厂类可以创建多个具体产品类的实例。   
    
区别：
工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。   
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。



工厂方法模式： 一个抽象产品类，可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂模式： 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。 一个抽象工厂类，可以派生出多个具体工厂类。 每个具体工厂类可以创建多个具体产品类的实例。 区别： 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。 工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。


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必须搜索对象的类的方法表才能找到一个合适的方法。这是因为实现同一个接口的这些类中，不一定所有的接口中的方法在类方法区中的偏移量都是一样的。他们有可能会不一样。这样的话可能就要搜索方法表才能确认要调用的方法在哪里。

而通过“类引用”来调用一个方法的时候，直接通过偏移量就可以找到要调用的方法的位置了。【因为子类中的方法的偏移量跟父类中的偏移量是一致的】

所以，通过接口引用调用方法会比类引用慢一些。

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

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