访问者模式应用场景

❶ 设计模式都有哪些

总体来说设计模式分为三大类：

一、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

二、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

三、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1、工厂方法模式：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，这就用到工厂方法模式。

创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

2、抽象工厂模式：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

3、单例模式：

单例对象（Singleton）是一种常用的设计模式。在java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

（1）某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

（2）省去了new操作符，降低了系统内存的使用频率，减轻GC压力。

（3）有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

4、建造者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

5、原型模式：

原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类。

6、适配器模式：

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

7、装饰器模式：

顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。

8、代理模式：

代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。

9、外观模式：

外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口。

10、桥接模式：

桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样。

JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。

11、组合模式：

组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。使用场景：将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，数等。

12、享元模式：

享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。

13、策略模式：

策略模式定义了一系列算法，并将每个算法封装起来，使其可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。

14、模板方法模式：

一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。

15、观察者模式：

观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。

其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。

16、迭代子模式：

顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。

17、责任链模式：

责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。

18、命令模式：

命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开。

19、备忘录模式：

主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。

20、状态模式：

状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。

21、访问者模式：

访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。

若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。

22、中介者模式：

中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。

如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。

23、解释器模式：

解释器模式一般主要应用在OOP开发中的编译器的开发中，所以适用面比较窄。

(1)访问者模式应用场景扩展阅读：

介绍三本关于设计模式的书：

1、《设计模式：可复用面向对象软件的基础》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 机械工业出版社

2、《软件秘笈：设计模式那点事》

作者：郑阿奇

出版社：电子工业出版社

3、《设计模式：基于C#的工程化实现及扩展》

作者：王翔

出版社：电子工业出版社

❷ 软件设计原则有哪些

七大设计原则
开闭原则
依赖导倒置原则
单一职责原则
接口隔离原则
迪米特原则
里氏替换原则
合成复用原则

设计模式-创建型模式
工厂方法模式
抽象工厂模式
建造者模式
单例模式
原型模式

设计模式-结构性模式
适配器模式
装饰者模式
代理模式
外观模式
桥接模式
组合模式
享元模式

设计模式-行为型模式
策略模式
模板方法模式
观察者模式
访问者模式
迭代器模式
责任链模式
中介者模式
解释器模式
状态模式
命令模式
备忘录模式
软件设计原则介绍
所以，可以说软件系统是连接需求分析、硬件系统以及使得系统实现的桥梁，对软件的设计应首先了解软件设计的设计原则。
设计原则
(1)可靠性
软件系统的规模越做越大越加复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。
(2)健壮性
健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。
(3)可修改性
要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。
(4)容易理解
软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。
(5)程序简便
(6)可测试性
可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。
(7)效率性
软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。
(8)标准化原则
在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。
(9)先进性
满足客户需求，系统性能可靠，易于维护。
(10)可扩展性
软件设计完要留有升级接口和升级空间。对扩展开放，对修改关闭。
（11）安全性
安全性要求系统能够保持用户信息、操作等多方面的安全要求，同时系统本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。

❸ 深入分析Java Web技术内幕的图书目录

第1章 深入Web请求过程 1
1.1 B/S网络架构概述 2
1.2 如何发起一个请求 4
1.3 HTTP协议解析 6
1.3.1 查看HTTP信息的工具 8
1.3.2 浏览器缓存机制 9
1.4 DNS域名解析 12
1.4.1 DNS域名解析过程 12
1.4.2 跟踪域名解析过程 15
1.4.3 清除缓存的域名 18
1.4.4 几种域名解析方式 19
1.5 CDN工作机制 20
1.5.1 CDN架构 20
1.5.2 负载均衡 21
1.6 总结 24
第2章 深入分析Java I/O的工作机制 25
2.1 Java的I/O类库的基本架构 25
2.1.1 基于字节的I/O操作接口 26
2.1.2 基于字符的I/O操作接口 27
2.1.3 字节与字符的转化接口 28
2.2 磁盘I/O工作机制 29
2.2.1 几种访问文件的方式 29
2.2.2 Java访问磁盘文件 33
2.2.3 Java序列化技术 34
2.3 网络I/O工作机制 36
2.3.1 TCP状态转化 37
2.3.2 影响网络传输的因素 39
2.3.3 Java Socket的工作机制 39
2.3.4 建立通信链路 40
2.3.5 数据传输 41
2.4 NIO的工作方式 41
2.4.1 BIO带来的挑战 41
2.4.2 NIO的工作机制 42
2.4.3 Buffer的工作方式 45
2.4.4 NIO的数据访问方式 47
2.5 I/O调优 49
2.5.1 磁盘I/O优化 49
2.5.2 TCP网络参数调优 50
2.5.3 网络I/O优化 52
2.6 设计模式解析之适配器模式 56
2.6.1 适配器模式的结构 56
2.6.2 Java I/O中的适配器模式 57
2.7 设计模式解析之装饰器模式 57
2.7.1 装饰器模式的结构 58
2.7.2 Java I/O中的装饰器模式 58
2.8 适配器模式与装饰器模式的区别 59
2.9 总结 59
第3章 深入分析Java Web中的中文编码问题 60
3.1 几种常见的编码格式 60
3.1.1 为什么要编码 60
3.1.2 如何“翻译” 61
3.2 Java中需要编码的场景 63
3.2.1 I/O操作中存在的编码 63
3.2.2 内存操作中的编码 65
3.3 Java中如何编解码 66
3.3.1 按照ISO-8859-1编码 68
3.3.2 按照GB2312编码 69
3.3.3 按照GBK编码 70
3.3.4 按照UTF-16编码 70
3.3.5 按照UTF-8编码 71
3.3.6 UTF-8编码代码片段 71
3.3.7 几种编码格式的比较 73
3.4 Java Web中涉及的编解码 73
3.4.1 URL的编解码 75
3.4.2 HTTP Header的编解码 78
3.4.3 POST表单的编解码 78
3.4.4 HTTP BODY的编解码 79
3.5 JS中的编码问题 80
3.5.1 外部引入JS文件 80
3.5.2 JS的URL编码 81
3.5.3 其他需要编码的地方 83
3.6 常见问题分析 83
3.6.1 中文变成了看不懂的字符 83
3.6.2 一个汉字变成一个问号 84
3.6.3 一个汉字变成两个问号 84
3.6.4 一种不正常的正确编码 85
3.7 总结 86
第4章 Javac编译原理 87
4.1 Javac是什么 88
4.2 Javac编译器的基本结构 88
4.3 Javac工作原理分析 90
4.3.1 词法分析器 91
4.3.2 语法分析器 98
4.3.3 语义分析器 103
4.3.4 代码生成器 113
4.4 设计模式解析之访问者模式 116
4.4.1 访问者模式的结构 117
4.4.2 Javac中访问者模式的实现 118
4.5 总结 119
第5章 深入class文件结构 120
5.1 JVM指令集简介 120
5.1.1 类相关的指令 122
5.1.2 方法的定义 123
5.1.3 属性的定义 124
5.1.4 其他指令集 125
5.2 class文件头的表示形式 133
5.3 常量池 137
5.3.1 UTF8常量类型 140
5.3.2 Fieldref、Methodref常量类型 141
5.3.3 Class常量类型 141
5.3.4 NameAndType常量类型 142
5.4 类信息 142
5.5 Fields和Methods定义 143
5.6 类属性描述 147
5.7 Javap生成的class文件结构 148
5.7.1 LineNumberTable 150
5.7.2 LocalVariableTable 151
5.8 总结 153
第6章 深入分析ClassLoader 工作机制 154
6.1 ClassLoader类结构分析 155
6.2 ClassLoader的等级加载机制 156
6.3 如何加载class文件 159
6.3.1 加载字节码到内存 159
6.3.2 验证与解析 161
6.3.3 初始化Class对象 161
6.4 常见加载类错误分析 161
6.4.1 ClassNotFoundException 161
6.4.2 NoClassDefFoundError 162
6.4.3 UnsatisfiedLinkError 163
6.4.4 ClassCastException 164
6.4.5 ExceptionInInitializerError 165
6.5 常用的ClassLoader分析 166
6.6 如何实现自己的ClassLoader 170
6.6.1 加载自定义路径下的class文件 170
6.6.2 加载自定义格式的class文件 172
6.7 实现类的热部署 174
6.8 Java应不应该动态加载类 176
6.9 总结 177
第7章 JVM体系结构与工作方式 178
7.1 JVM体系结构 178
7.1.1 何谓JVM 178
7.1.2 JVM体系结构详解 181
7.2 JVM工作机制 183
7.2.1 机器如何执行代码 183
7.2.2 JVM为何选择基于栈的架构 184
7.2.3 执行引擎的架构设计 185
7.2.4 执行引擎的执行过程 186
7.2.5 JVM方法调用栈 191
7.3 总结 195
第8章 JVM内存管理 196
8.1 物理内存与虚拟内存 197
8.2 内核空间与用户空间 198
8.3 Java中哪些组件需要使用内存 199
8.3.1 Java堆 199
8.3.2 线程 199
8.3.3 类和类加载器 200
8.3.4 NIO 200
8.3.5 JNI 201
8.4 JVM内存结构 201
8.4.1 PC寄存器 202
8.4.2 Java栈 202
8.4.3 堆 203
8.4.4 方法区 203
8.4.5 运行时常量池 204
8.4.6 本地方法栈 204
8.5 JVM内存分配策略 204
8.5.1 通常的内存分配策略 205
8.5.2 Java中内存分配详解 205
8.6 JVM内存回收策略 210
8.6.1 静态内存分配和回收 210
8.6.2 动态内存分配和回收 211
8.6.3 如何检测垃圾 211
8.6.4 基于分代的垃圾收集算法 213
8.7 内存问题分析 222
8.7.1 GC日志分析 222
8.7.2 堆快照文件分析 225
8.7.3 JVM Crash日志分析 225
8.8 实例1 231
8.9 实例2 233
8.10 实例3 235
8.11 总结 240
第9章 Servlet工作原理解析 241
9.1 从Servlet容器说起 241
9.1.1 Servlet容器的启动过程 242
9.1.2 Web应用的初始化工作 245
9.2 创建Servlet实例 247
9.2.1 创建Servlet对象 248
9.2.2 初始化Servlet 248
9.3 Servlet体系结构 250
9.4 Servlet如何工作 253
9.5 Servlet中的Listener 255
9.6 Filter如何工作 257
9.7 Servlet中的url-pattern 259
9.8 总结 260
第10章 深入理解Session与Cookie 261
10.1 理解Cookie 262
10.1.1 Cookie属性项 262
10.1.2 Cookie如何工作 263
10.1.3 使用Cookie的限制 266
10.2 理解Session 267
10.2.1 Session与Cookie 267
10.2.2 Session如何工作 268
10.3 Cookie安全问题 271
10.4 分布式Session框架 272
10.4.1 存在哪些问题 272
10.4.2 可以解决哪些问题 273
10.4.3 总体实现思路 273
10.5 Cookie压缩 278
10.6 表单重复提交问题 280
10.7 总结 281
第11章 Tomcat的系统架构与 设计模式 282
11.1 Tomcat总体设计 282
11.1.1 Tomcat总体结构 283
11.1.2 Connector组件 289
11.1.3 Servlet容器Container 294
11.1.4 Tomcat中的其他组件 305
11.2 Tomcat中的设计模式 305
11.2.1 门面设计模式 305
11.2.2 观察者设计模式 307
11.2.3 命令设计模式 309
11.2.4 责任链设计模式 310
11.3 总结 312
第12章 Jetty的工作原理解析 313
12.1 Jetty的基本架构 313
12.1.1 Jetty的基本架构简介 313
12.1.2 Handler的体系结构 315
12.2 Jetty的启动过程 316
12.3 接受请求 317
12.3.1 基于HTTP协议工作 317
12.3.2 基于AJP工作 319
12.3.3 基于NIO方式工作 322
12.4 处理请求 323
12.5 与Jboss集成 326
12.6 与Tomcat的比较 327
12.6.1 架构比较 327
12.6.2 性能比较 328
12.6.3 特性比较 328
12.7 总结 329
第13章 Spring框架的设计理念与 设计模式分析 330
13.1 Spring的骨骼架构 330
13.1.1 Spring的设计理念 331
13.1.2 核心组件如何协同工作 332
13.2 核心组件详解 333
13.2.1 Bean组件 333
13.2.2 Context组件 335
13.2.3 Core组件 336
13.2.4 Ioc容器如何工作 338
13.3 Spring中AOP特性详解 348
13.3.1 动态代理的实现原理 348
13.3.2 Spring AOP如何实现 351
13.4 设计模式解析之代理模式 354
13.4.1 代理模式原理 354
13.4.2 Spring中代理模式的实现 354
13.5 设计模式解析之策略模式 357
13.5.1 策略模式原理 357
13.5.2 Spring中策略模式的实现 358
13.6 总结 358
第14章 Spring MVC工作机制与 设计模式 360
14.1 Spring MVC的总体设计 360
14.2 Control设计 365
14.2.1 HandlerMapping初始化 366
14.2.2 HandlerAdapter初始化 368
14.2.3 Control的调用逻辑 369
14.3 Model设计 370
14.4 View设计 371
14.5 框架设计的思考 373
14.5.1 为什么需要框架 373
14.5.2 需要什么样的框架 373
14.5.3 框架设计的原则 374
14.5.4 “指航灯” 374
14.5.5 最基本的原则 374
14.6 设计模式解析之模板模式 375
14.6.1 模板模式的结构 375
14.6.2 Spring MVC中的模板模式示例 376
14.7 总结 377
第15章 深入分析Ibatis框架之系统 架构与映射原理 378
15.1 Ibatis框架主要的类层次结构 378
15.2 Ibatis框架的设计策略 379
15.3 Ibatis框架的运行原理 381
15.4 示例 383
15.5 Ibatis对SQL语句的解析 385
15.6 数据库字段映射到Java对象 386
15.7 示例运行的结果 388
15.8 设计模式解析之简单工厂模式 388
15.8.1 简单工厂模式的实现原理 388
15.8.2 Ibatis中的简单工厂模式示例 389
15.9 设计模式解析之工厂模式 390
15.9.1 工厂模式的实现原理 390
15.9.2 Ibatis中的工厂模式示例 391
15.10 总结 392
第16章 Velocity工作原理解析 394
16.1 Velocity总体架构 395
16.2 JJTree渲染过程解析 398
16.2.1 #set语法 402
16.2.2 Velocity的方法调用 403
16.2.3 #if、#elseif和#else语法 406
16.2.4 #foreach语法 407
16.2.5 #parse语法 409
16.3 事件处理机制 410
16.4 常用优化技巧 413
16.4.1 减少树的总节点数量 413
16.4.2 减少渲染耗时的节点数量 413
16.5 与JSP比较 414
16.5.1 JSP渲染机制 414
16.5.2 Velocity与JSP 420
16.6 设计模式解析之合成模式 420
16.6.1 合成模式的结构 420
16.6.2 Velocity中合成模式的实现 421
16.7 设计模式解析之解释器模式 422
16.7.1 解释器模式的结构 422
16.7.2 Velocity中解释器模式的实现 423
16.8 总结 423
第17章 Velocity优化实践 424
17.1 现实存在的问题 424
17.2 优化的理论基础 425
17.2.1 程序语言的三角形结构 425
17.2.2 数据结构减少抽象化 426
17.2.3 简单的程序复杂化 426
17.2.4 减少翻译的代价 427
17.2.5 变的转化为不变 427
17.3 一个高效的模板引擎的实现思路 427
17.3.1 vm模板如何被编译 429
17.3.2 方法调用的无反射优化 436
17.3.3 字符输出改成字节输出 439
17.4 优化的成果 440
17.4.1 char转成byte 440
17.4.2 无反射执行 441
17.5 其他优化手段 442
17.6 总结 442

❹ apache-httpd的三种模式

apache httpd-2.4

新增模块；

mod_proxy_fcgi(可提供 fcgi 代理）

mod_ratelimit（限制用户带宽）

mod_request（请求模块，对请求做过滤）

mod_remoteip（匹配客户端的 IP 地址）

对于基于 IP 的访问控制做了修改，不再支持 allow,deny,order 机制，而是统一使用 require进行

还新增以下几条新特性；

1、MPM 支持在运行时装载;不过要开启这种特性，在编译安装要启用这三种功能；

--enable-mpms-shared=all --with-mpm=event

2、支持 event

3、支持异步读写

4、在每个模块及每个目录上指定日志级别

5、增强版的表达式分析器

6、每请求配置：<If>, <Elseif>

7、毫秒级别的 keepalive timeout

8、基于 FQDN 的虚拟主机不再需要 NameVirtualHost 指令

9、支持使用自定义变量

安装时HTTPd 可以添加许多模块

相关模块解析：

--enable-so：支持动态共享模块（即打开 DSO 支持）

--enable-rewrite：支持 url 重写

--enable-ssl：支持 ssl

--with-ssl=/usr/local/openssl:指定 ssl 安装位置

--enable-cgi：启用 cgi

--enable-cgid:MPM 使用的是 event 或 worker 要启用 cgid

--enable-moles=most:明确指明要静态编译到 httpd 二进制文件的模块，<MODULE-LIST>为

空格分隔的模块名列表、all 或者 most，all 表示包含所有模块，most 表示包含大部分常用模

块

--enable-mpms-shared=all:启用 MPM 所有支持的模式，这样 event、worker、prefork 就会以

模块化的方式安装，要用哪个就在 httpd.conf 里配置就好了。

--with-mpm=event:指定启用的 mpm 模式，默认使用 enevt 模式，在 apache 的早期版本 2.0

默认 prefork,2.2 版本是 worker，2.4 版本是 event.

--with-pcre=/usr/local/pcre:支持 pcre

--with-z=/usr/local/zlib:使用 zlib 压缩库

--with-apr=/usr/local/apr:指定 apr 的安装路径

--with-apr-util=/usr/local/apr-util:指定 apr-util 的安装路径

--enable-expires:激活彧通过配置文件控制 HTTP 的“Expires:”和“Cache-Control:”头内容，即

对网站图片、js、css 等内容，提供客户端浏览器缓存的设置。这个是 apache 调优的一个重

要选项之一。

--enable-deflate:提供对内容的压缩传输编码支持，一般是 html、js、css 等内容的站点。使

用此参数会打打提高传输速度，提升访问者访问的体验。在生产环境中，这是 apache 调优

的一个重要选项之一。

Apache 的优化配置：

apache 所运行的硬件环境都是对性能影响最大的因素，即使不能对硬件进行升级，也最好

给 apache 一个单独的主机以免受到其他应用的干扰。各个硬件指标中，对性能影响最大的

是内存，对于静态内容（图片、javascript 文件、css 文件等），它决定了 apache 可以缓存多

少内容，它缓存的内容越多，在硬盘上读取内容的机会就越少，大内存可以极大提高静态站

点的速度；对动态高负载站点来说，每个请求保存的时间更多一些，apache 的 mpm 模块会

为每个请求派生出相应的进程或线程分别处理，而进程或线程的数量与内存的消耗近似成正

比，因此增大内存对提高动态站点的负载和运行速度也极为有利

其次是硬盘的速度，静态站点尤为突出，apache 不断的在读取文件并发送给相应的请求，

硬盘的读写是极其频繁的；动态站点也要不断的加载 web 程序(php 等)，一个请求甚至要读

取十几个文件才能处理完成，因此尽可能的提高硬盘速度和质量对提高 apache 的性能是有

积极意义的。

最后是 cpu 和网络，cpu 影响的是 web 程序执行速度，网络影响流量大小。

apache  的工作模式：

Apache HTTP 服务器被设计为一个强大的、灵活的能够在多种平台以及不同环境下工作的服

务器。这种模块化的设计就叫做“多进程处理模块”（Multi-Processing Mole，MPM），也叫

做工作模式。

Prefork 模式（一个非线程型的）：

其主要工作方式是：当 Apache 服务器启动后，mpm_prefork 模块会预先创建多个子进程(默

认为 5 个)，每个子进程只有一个线程，当接收到客户端的请求后，mpm_prefork 模块再将

请求转交给子进程处理，并且每个子进程同时只能用于处理单个请求。如果当前的请求数将

超过预先创建的子进程数时，mpm_prefork 模块就会创建新的子进程来处理额外的请求。

Apache 总是试图保持一些备用的或者是空闲的子进程用于迎接即将到来的请求。这样客户

端的请求就不需要在接收后等候子进程的产生。

由于在 mpm_prefork 模块中，每个请求对应一个子进程，因此其占用的系统资源相对其他

两种模块而言较多。不过 mpm_prefork 模块的优点在于它的每个子进程都会独立处理对应

的单个请求，这样，如果其中一个请求出现问题就不会影响到其他请求。Prefork 在效率上

要比 Worker 要高，但是内存使用大得多不擅长处理高并发的场景。

Apache 在 prefork 工作模式下影响性能的重要参数说明

# prefork MPM

<IfMole mpm_prefork_mole>

StartServers 5

#apache 启动时候默认开始的子进程数

MinSpareServers 5

#最小的闲置子进程数

MaxSpareServers 10

#最大的闲置子进程数

MaxRequestWorkers 250

#MaxRequestWorkers 设 置 了 允 许 同 时 的 最 大 接 入 请 求 数 量 。 任 何 超 过MaxRequestWorkers 限制的请求将进入等候队列，在 apache2.3.1 以前的版本

MaxRequestWorkers 被称为 MaxClients，旧的名字仍旧被支持。

MaxConnectionsPerChild 500

#设置的是每个子进程可处理的请求数。每个子进程在处理了“MaxConnectionsPerChild”

个请求后将自动销毁。0 意味着无限，即子进程永不销毁。虽然缺省设为 0 可以使每个

子进程处理更多的请求，但如果设成非零值也有两点重要的好处：1、可防止意外的内

存泄漏。2、在服务器负载下降的时侯会自动减少子进程数。因此，可根据服务器的负

载来调整这个值。在 Apache2.3.9 之前称之为 MaxRequestsPerChild。

</IfMole>

注 1：MaxRequestWorkers 是这些指令中最为重要的一个，设定的是 Apache 可以同时处理

的请求，是对 Apache 性能影响最大的参数。如果请求总数已达到这个值（可通过 ps -ef|grep

http|wc -l 来确认），那么后面的请求就要排队，直到某个已处理请求完毕。这就是系统资源

还剩下很多而 HTTP 访问却很慢的主要原因。虽然理论上这个值越大，可以处理的请求就越

多，建议将初始值设为(以 Mb 为单位的最大物理内存/2),然后根据负载情况进行动态调整。

比如一台 4G 内存的机器，那么初始值就是 4000/2=2000。

注 2：prefork 控制进程在最初建立“StartServers”个子进程后，为了满足 MinSpareServers 设

置的需要创建一个进程，等待一秒钟，继续创建两 个，再等待一秒钟，继续创建四个……如

此按指数级增加创建的进程数，最多达到每秒 32 个，直到满足 MinSpareServers 设置的值为

止。这种模式 可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。

MaxSpareServers 设置了最大的空闲进程数，如果空闲进程数大于这个 值，Apache 会自动 kill

掉一些多余进程。这个值不要设得过大，但如果设的值比 MinSpareServers 小，Apache 会自

动把其调整为 MinSpareServers+1。如果站点负载较大，可考虑同时加大 MinSpareServers 和

MaxSpareServers。

注 3：ServerLimit 和 MaxClients（MaxRequestWorkers）有什么区别呢？

是因为在 apache1 时代，控制最大进程数只有 MaxClients 这个参数，并且这个参数最大值为

256，并且是写死了的，试图设置为超过 256 是无效的，这是由于 apache1 时代的服务器硬

件限制的。但是 apache2 时代由于服务器硬件的升级，硬件已经不再是限制，所以使用

ServerLimit 这个参数来控制最大进程数，ServerLimit 值>=MaxClient 值才有效。ServerLimit

要放在 MaxClients 之前，值要不小于 MaxClients。

注 4：查看 Apache 加载的模块

[root@www ~]#apachectl -t -D DUMP_MODULES

或

[root@www ~]# apachectl -M

或

[root@www ~]# apachectl –l (小写 L，只显示静态模块)

如何查看 Apache 的工作模式呢？可以使用 httpd -V 命令查看，另外使用 httpd -l 也可以查

看到

注 5：如何修改 prefork 参数和启用 prefork 模式

1.[root@www ~]# vi /usr/local/http-2.4.23/conf/extra/httpd-mpm.conf

2.[root@www ~]# vi /usr/local/http-2.4.23/conf/httpd.conf

LoadMole mpm_prefork_mole moles/mod_mpm_prefork.so

Include conf/extra/httpd-mpm.conf

3 重启httpd

Worker 模式(多线程多进程)：

和 prefork 模式相比，worker 使用了多进程和多线程的混合模式，worker 模式也同样会先预

派生一些子进程，然后每个子进程创建一些线程，同时包括一个监听线程，每个请求过来会

被分配到一个线程来服务。线程比起进程会更轻量，因为线程是通过共享父进程的内存空间，

因此，内存的占用会减少一些，在高并发的场景下会比 prefork 有更多可用的线程，表现会

更优秀一些；另外，如果一个线程出现了问题也会导致同一进程下的线程出现问题，如果是

多个线程出现问题，也只是影响 Apache 的一部分，而不是全部。由于用到多进程多线程，

需要考虑到线程的安全了，在使用 keep-alive 长连接的时候，某个线程会一直被占用，即使

中间没有请求，需要等待到超时才会被释放（该问题在 prefork 模式下也存在）

总的来说，prefork 方式速度要稍高于 worker，然而它需要的 cpu 和 memory 资源也稍多于

woker。

Apache 在 worker 工作模式下影响性能的重要参数说明

# worker MPM

<IfMole mpm_worker_mole>

StartServers 3

#apache 启动时候默认开始的子进程数

MinSpareThreads 75

#最小空闲数量的工作线程

MaxSpareThreads 250

#最大空闲数量的工作线程

ThreadsPerChild 25

#每个子进程产生的线程数量

MaxRequestWorkers 400

#与 prefork 模式相同

MaxConnectionsPerChild 0

#与 prefork 模式相同

</IfMole>

注 1：Worker 由主控制进程生成“StartServers”个子进程，每个子进程中包含固定的

ThreadsPerChild 线程数，各个线程独立地处理请求。同样， 为了不在请求到来时再生成线

程，MinSpareThreads 和 MaxSpareThreads 设置了最少和最多的空闲线程数；

而 MaxRequestWorkers 设置了同时连入的 clients 最大总数。如果现有子进程中的线程总数不

能满足负载，控制进程将派生新的子进程

MinSpareThreads 和 MaxSpareThreads 的最大缺省值分别是 75 和 250。这两个参数对 Apache

的性能影响并不大，可以按照实际情况相应调节 。

注 2：ThreadsPerChild 是 worker MPM 中与性能相关最密切的指令。ThreadsPerChild 的最大

缺省值是 64，如果负载较大，64 也是不够的。这时要显式使用 ThreadLimit 指令，它的最大

缺省值是 20000。

注 3：Worker 模式下所能同时处理的请求总数是由子进程总数乘以 ThreadsPerChild 值决定

的，应该大于等于 MaxRequestWorkers。如果负载很大，现有的子进程数不能满足时，控制

进程会派生新的子进程。默认最大的子进程总数是 16，加大时 也需要显式声明 ServerLimit

（系统配置的最大进程数量，最大值是20000）。需要注意的是，如果显式声明了 ServerLimit，

那么它乘以 ThreadsPerChild的值必须大于等于MaxRequestWorkers，而且MaxRequestWorkers

必须是 ThreadsPerChild 的整数倍，否则 Apache 将会自动调节到一个相应值。

注 4：进程与线程的区别

线程是指进程内的一个执行单元,也是进程内的可调度实体.

与进程的区别:

(1)地址空间:进程内的一个执行单元;进程至少有一个线程;它们共享进程的地址空间;而进程

有自己独立的地址空间;

(2)资源拥有:进程是资源分配和拥有的单位,同一个进程内的线程共享进程的资源

(3)线程是处理器调度的基本单位,但进程不是.

(4)二者均可并发执行.

进程和线程都是由操作系统所体会的程序运行的基本单元，系统利用该基本单元实现系统对

应用的并发性。

进程和线程的区别在于：

简而言之,一个程序至少有一个进程,一个进程至少有一个线程.

线程的划分尺度小于进程，使得多线程程序的并发性高。

另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程

序的运行效率。

Event 模式：

这是 Apache 最新的工作模式，是 worker 模式的变种，它把服务进程从连接中分离出来，一

worker 模式不同的是在于它解决了 keep-alive 长连接的时候占用线程资源被浪费的问题，在

event 工作模式中，会有一些专门的线程用来管理这些 keep-alive 类型的线程，当有真实请

求过来的时候，将请求传递给服务器的线程，执行完毕后，又允许它释放。这增强了在高并

发场景下的请求处理。event 模式不能很好的支持 https 的访问（HTTP 认证相关的问题）。