2 产品功能

1）支持SOA服务路由

2）支持SOA服务编排：对多个服务进行调用流程编排

Ø 通过sBPEL语法（xml风格）描述业务流程

Ø 编排流程支持：并行调用、串行调用、跳转流程，支持根据服务任意返回值、流程内变量等进行跳转或赋值操作。

Ø 支持对编排结果嵌套编排

Ø 编排目标原生支持sBPM自定义二进制协议，通过外部适配支持对HTTP协议以及其他协议进行编排。

3）支持服务编排语法进行服务开发

Ø 通过异步插件机制可任意扩展编排目标，已支持：本地内存、memcache、redis、mysql、oracle，且针对各数据源特点不同分别支持一致性hash、分库分表等策略。通过对基础存储进行编排达到服务开发的目的

Ø 通过同步插件机制可任意扩展流程内编排逻辑，已支持大量常用逻辑插件。

4）提供BPEL4WS语法向sBPEL语法转换工具，可使用BPEL4WS可视化流程编排工具进行编排

5）提供配置接口、明细日志、性能数据接口、业务量数据接口、告警接口等支持。尤其对实时日志分析提供特别支持。

6）对编排结果接口，提供HTTP/TCP两类通用授权网关对外暴露。提供TCP接口的同步、异步IPC调用。

7）对编排结果接口，提供可视化测试用例编辑器以及自动化运行器。

3 类似产品比较

在后端服务器领域，没有类似支持SOA服务编排的产品，其他领域产品存在部分类似点，比较如下：

1)    sBPM与ESB比较

ESB是对已存在的复杂异构环境的黏合剂，主要强调消息路由、协议适配。
      sBPM拥有完善产品线，虽有扩展机制支持组合已有系统，但更侧重于从无到有开发全新系统；sBPM虽支持消息路由功能，但更强调服务编排功能。
      通过ESB的协议适配机制可以大大加强sBPM的编排能力，可作为sBPM的补充。

2）sBPM与BPEL4WS类产品、jBPM比较

      BPEL4WS使用XML语法描述业务流程，由BEA、IBM和Microsoft编写和公布，是针对WEB服务的SOA组合编排，代表产品众多，不详举。
      sBPM使用sBPEL描述业务流程，提供BPEL4WS语法向本语法翻译工具，可复用BPEL4WS的可视化流程开发工具，与BPEL4WS定位于WEB服务编排不同，sBPM侧重于高性能后端服务，通过内置插件以及扩展服务不限编排组合对象，可以是基础服务、cache、本地内存、redis、mysql、oracle、http接口等。
      jBPM使用自定义jpdl描述业务流程，提供可视化流程编辑器、调试器，定位为信息化、工作流领域，不强调编排目标与性能，更重视流程数据持久化、与人交互流程。

3)    sBPM与Node.js比较
Node.js相对前两着，和sBPM更为接近。它定位为快速构建异步高性能服务后端，和传统web容器相同，仅支持单线程。它强调IO异步，以类似网络proactor模型设置回调方式进行开发，使用javascript语言进行开发，容易获得已有前端人员认可，同时也带来了不可避免的调式工作。

      sBPM和node.js同样定位为快速构建异步高性能服务后端，强调运行时异步性能，默认线程和CPU数量相同。和node.js不同，sBPM不需开发，以同步方式来描述异步流程，配置思路符合业务思维，配合级联部署、层层组合较容易组装产生平台级的强大服务。sBPM属完整产品，对接口日志、各接口业务量、依赖接口业务量、接口耗时、各依赖耗时、告警分布做了统一封装。

      Node.js目标人群仍旧是开发人员。而sBPM框架不再需要传统开发、代码调试角色。在云计算时代，我相信sBPM是云平台发展的必然趋势，传统后端开发角色终将被合架构师、开发角色、业务运维角色为一体的业务配置角色所替代。

4 产品优点

1） 产品线完善：覆盖编排运行容器、可视化编排工具、可视化测试工具、运营支撑平台等。

2） 缩短产品开发时间：基于sBPM产品开发新产品，完全配置方式，颠覆传统开发方式，将产品研发时间完全缩短到产品需求提炼过程。

3） 提高产品质量：开发过程不会引入bug，节省测试成本。

4） 产品高可扩展、可维护：流程配置完全贴近业务本质，保护流程投资。流程编排方式更容易产生更强大、功能更完善的产品，维护更直接简单。

5） 高性能：sBPM将性能与稳定性做为本产品第一竞争力，容器在初始化阶段解析流程文件到内存结构，运行中采用全异步机制。基于sBPM配置产生的产品天生具有高性能，高于手写方式。

6） 可运营性：sBPM产品融合我方实际运营经验，关注配置、告警、性能、日志、安全等方面。

5 产品使用情况

通过近3年持续发展与推广，sBPM已在盛大基础平台内广泛使用，涵盖认证、注册、用户信息、计费、安全等业务。目前sBPM产品已管理过10T关系型数据库、几十亿记录，涵oracle、mysql、hbase、memcache、redis多种数据源，每日外部请求量近10亿次，内部组合调用过30亿次。

6 产品展望

1）将sBPM独立产品化，与内部运营支撑系统藕荷部分重构为插件接口，裁减掉不适合产品化部分。

在CPU密集型服务器的设计中，说道“线程是给那些不能将程序执行序转换成状态机的笨人用的”，而有了协程，我们有了一种新的简化编程的方法。将协程用于网络层，可以手动实现类似select的功能，用于多对象参与的复杂中间状态，可以简化编程。
但从整体性能角度看，协程则是鸡肋的存在，从几年前出现boost.Coroutine，到现在该项目停止开发，boost引入更多其他方案asio/mpl/statechart，协程一路蹒跚。
七 总结
在当前硬件体系架构下，服务器性能的关键仍然是传统的cpu/io/memory.
cpu密集型的服务器，需要最大限度充分利用所有cpu，以及尽量少的进行内存申请/内存复制。
IO密集型服务器，需要最大限度提高io能力，为达到该目的，可以在非同步线程牺牲对cpu的利用率/牺牲对memory的高效使用，一切为提高io并发能力服务。
八  后记
特别感谢张杰同学代替我编译探测程序代码，让我有时间码点文字。

三 mutex机制
mutex属于os之上的再次封装实现。在linux2.6内核上，线程库为nptl，其中的mutex基于futex机制实现，它的实现原理，简单说就是spinlock+semaphore，首先使用spinlock尝试，可以拿到锁则直接向下执行，拿不到锁则执行semaphore机制，陷入内核态，进入线程切换。
在多核环境下，当mutex保护的代码段内无io操作，执行很快时，大多数情况下通过spinlock都可拿到锁，不需要陷入内核态。

四 为智能指针正名(boost)
智能指针的引用计数仅仅为一个整型变量的增减，属于执行迅速的典型，使用spinlock机制保护，最新boost版本中仅仅是spinlock，而非mutex。从性能角度说，使用智能指针的现象是cpu略微上升（循环尝试导致），而并发量/单个请求的响应时间并无明显影响。proactor机制实现的网络层，智能指针基本无法绕过，刻意避免带来的只能是丑陋的代码和维护量的上升。但线程之间尽量避免传递指针（智能指针），通过传递id等代替。
智能指针有它使用的场景，不能滥用，也不能刻意避免。

1 单元测试对象概述

各个对象组织结构如下：

职责简述如下：

2 单元测试框架选型

当前存在很多流行的单元测试框架：衍生自JUnit的CppUnit，以及简化版本的CppUnitLite，Boost.Test测试框架，Google Test测试框架等。每个测试框架都很完善，都可胜任单元测试任务。

       从使用简单性考虑，依次是Boost.Test>>Google Test>>CppUnitLite>>CppUnit.

本文选择Boost.Test的单元测试框架讲解。对Google Test感兴趣的可参看http://www.cnblogs.com/coderzh/archive/2009/03/31/1426758.html。
 

3 Boost.Test UTF(Unit Test Framework)

3.1 LogLevel

讲解TestAssert前，先说下Boost测试框架的日志级别，有以下9个级别：

级别名称	说明
all / success	报告包括成功测试通知的所有日志信息
test_suite	显示测试套件信息
message	显示用户信息
warning	报告用户发出的警告
error	报告所有错误情况
cpp_exception	报告未捕获的 C++ 异常
system_error	报告系统引起的非致命错误 (例如，超时或浮点数异常)
fatal	用户或系统引起的致命错误 (例如，内存访问越界)
nothing	不报告任何信息

生成测试可执行程序后，可以通过指定--log_level参数指定日志接别。比如，最后可执行程序为testmini，执行./testmini --log_level=warning指定在warning级别运行，默认执行在error级别。

请特别关注级别中黑体部分，TestAssert中将使用到。

3.2 TestAssert

Boost.Test中测试断言包含如下3大类：

类别	功能	说明
WARN	打印warning日志，不增加失败引用计数，继续执行程序	检验不太重要但是正确的方面
CHECK	打印error日志，增加失败引用计数，继续执行程序	实现 assertions
REQUIRE	增加失败应用计数，中断程序的运行	失败就不应该让程序继续运行则使用

Boost.Test中详细测试断言包含如下几种：

TestAssert类型	说明	举例
BOOST_WARN	WARN型预言检测	BOOST_WARN(2+2==4);
BOOST_CHECK	CHECK型预言检测	BOOST_CHECK(2+2==4);
BOOST_REQUIRE	REQUIRE型预言检测	BOOST_REQUIRE(2+2==4);
BOOST_WARN_MESSAGE	WARN型预言检测，自定义日志	BOOST_WARN_MESSAGE（2+2==4，"description…" );
BOOST_CHECK_MESSAGE	CHECK型预言检测，自定义日志	BOOST_CHECK_MESSAGE（2+2==4，"description…" );
BOOST_REQUIRE_MESSAGE	REQUIRE型预言检测，自定义日志	BOOST_ REQUIRE _MESSAGE（2+2==4，"description…" );
BOOST_ERROR	同BOOST_CHECK_MESSAGE( false, M )	if( 2+2 !=4 ) BOOST_ERROR( "description…" );
BOOST_FAIL	同BOOST_REQUIRE_MESSAGE( false, M )	if( 2+2 !=4 ) BOOST_FAIL( "description…" );
BOOST_WARN_EQUAL	WARN型左右值相等检测检测	BOOST_WARN_EQUAL(2+2,4);
BOOST_CHECK_EQUAL	CHECK型左右值相等检测检测	BOOST_CHECK_EQUAL(2+2,4);
BOOST_REQUIRE_EQUAL	REQUIRE型左右值相等检测检测	BOOST_REQUIRE_EQUAL(2+2,4);
该类还有不等，小于，大于，小于等于，大于等于的判别检测，此处只罗列WARN的，其他不再一一罗列：BOOST_WARN_NE/ BOOST_WARN_LT/ BOOST_WARN_LE/ BOOST_WARN_GT/ BOOST_WARN_GE
BOOST_WARN_THROW	WARN型，判别执行函数期，有异常抛出。	BOOST_WARN_THROW(executeSql(“select…”),oracle::ErrorCodeException);
BOOST_CHECK_THROW	CHECK型，判别执行函数期，有异常抛出。
BOOST_REQUIRE_THROW	REQUIRE型，判别执行函数期，有异常抛出。
BOOST_WARN_EXCEPTION	WARN型，执行函数，当预言为真时，捕获异常。	BOOST_WARN_THROW(executeSql(“select…”),oracle::ErrorCodeException,2+2==4);
BOOST_CHECK_EXCEPTION	CHECK型，执行函数，当预言为真时，捕获异常。
BOOST_REQUIRE_EXCEPTION	REQUIRE型，执行函数，当预言为真时，捕获异常。
BOOST_WARN_NO_THROW	WARN型，判别执行函数期，无异常抛出。	BOOST_WARN_NO_THROW(executeSql(“select…”));
BOOST_CHECK_NO_THROW	CHECK型，判别执行函数期，无异常抛出。
BOOST_REQUIRE_NO_THROW	REQUIRE型，判别执行函数期，无异常抛出。
BOOST_WARN_CLOSE	WARN型，判定左右值是否足够逼近。用于浮点数比较。	BOOST_WARN_CLOSE（2.1131,2.1132,0.01）
BOOST_CHECK_CLOSE	CHECK型，判定左右值是否足够逼近。用于浮点数比较
BOOST_REQUIRE_CLOSE	REQUIRE型，判定左右值是否足够逼近。用于浮点数比较
BOOST_WARN_SMALL	WARN型，判定值是否足够小（是否接近0）。用于浮点数比较	BOOST_WARN_CLOSE（0.1,0.01）
BOOST_CHECK_SMALL	CHECK型，判定值是否足够小（是否接近0）。用于浮点数比较
BOOST_REQUIRE_SMALL	REQUIRE型，判定值是否足够小（是否接近0）。用于浮点数比较

3.3 TestCase

对于TestCase/TestSuite等，Boost.Test既支持手动注册方式，也支持自动注册方式，当前Boost官方推荐自动注册方式，手动注册为了保持向前兼容保留，以后版本可能被移除。使用宏BOOST_AUTO_TEST_CASE即可自动注册测试用例。使用如下：

#include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(test_case_name) {     BOOST_CHECK(true); }

3.4 TestSuite

使用宏BOOST_AUTO_TEST_SUITE(test_suite_name)开始测试套件，使用BOOST_AUTO_TEST_SUITE_END()结束测试套件。使用举例：

#include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE(test_suite_name) BOOST_AUTO_TEST_CASE(test_case1) {     BOOST_CHECK(true); } BOOST_AUTO_TEST_CASE(test_case1) {     BOOST_CHECK(true); } BOOST_AUTO_TEST_SUITE_END()

3.5 MainTestSuite

使用宏BOOST_TEST_MODULE表明主测试套件，一个测试项目中只能存在一个主测试套件。使用举例：

#define BOOST_TEST_MODULE maintest #include <boost/test/unit_test.hpp>

3.6 TestFixture

测试夹具做测试前的准备工作和测试后的清理工作。而C++的RAII机制（构造函数申请资源，析构函数释放资源）恰好能满足该需求。因此Boost中直接使用普通类做夹具。实现夹具举例：该夹具在测试前将整数i初始化为5

struct MyFixture {     MyFixture():i(5){}     ~MyFixture(){}    Int I; };

    夹具可以和TestCase一起使用，也可以和TestSuite一起使用，也可以和MainTestSuite一起使用。

    使用宏BOOST_FIXTURE_TEST_CASE(test_case_name, fixure_name)代替BOOST_AUTO_TEST_CASE(test_case_name)即可在TestCase中使用夹具，举例如下：

BOOST_FIXTURE_TEST_CASE(test_case_name，MyFixture) {     BOOST_CHECK(i==5); }

    使用宏BOOST_FIXTURE_TEST_SUITE(suite_name, fixure_name)代替BOOST_AUTO_TEST_SUITE(suite_name)即可在TestSuite中使用夹具，举例如下：

BOOST_FIXTURE_TEST_SUITE(test_suite, MyFixture ); BOOST_AUTO_TEST_CASE (test_case1) {     BOOST_CHECK(i==5); } BOOST_AUTO_TEST_CASE(test_case2) {     BOOST_CHECK(++i==6); } BOOST_AUTO_TEST_SUITE_END()

       使用宏BOOST_GLOBAL_FIXTURE(MyFixture);将MyFixture声明为全局夹具，即可和MainTestSuite一起使用。

3.7 Boost.Test使用

对已经完成的项目做单元测试，假定该项目具有很好的测试性：

1） 对项目中的每个类对象创建一个测试套件，一个测试套件对应一个cpp文件。对类的每个类方法创建一个测试用例，这些测试用例均包含上前面的测试套件中。每个测试用例可以有多个测试断言，对该方法进行充分测试。

2） 在测试主文件中定义宏BOOST_TEST_MODULE，并包含所有的测试套件文件。

3） Linux下，将被测试项目编译成静态库（将main函数外的所有文件编译打包）供测试项目连接。Window下为测试项目做静态库工程，设置测试工程依赖该工程。并将头文件路径设置正确，即可编译运行。

附件为一示例项目以及对应单元测试工程举例，项目目录下make编译生成静态库以及可执行程序，test目录下make生成单元测试可执行程序。(略)
 

4 实行单元测试

4.1 现实困难

1、 内部依赖问题

类之间相互协作共同完成功能，类之间的依赖必不可少。为了测试某个类，必须实例化它依赖的类，而它依赖的类又可能依赖其他类，因此必须实例化其他类。如此一环扣一环，可能把整个项目大部分类都包含在了这次测试中，最后做的不是单元测试，而是挂着单元测试外壳的集成测试。

2、 外部依赖问题

很多项目，尤其是我们的网络应用服务器，运行期间需要依赖外部的其他服务器或者数据库或者本地的文件系统。而对很多外部的依赖很难模拟，或者说模拟成本太高，往往让测试者望而却步。

3、 函数本身问题

项目中的很多或者可能是大部分函数，是没有明确返回值或者无异常抛出，而只是和其他外设交互。难于使用测试断言判定。

以上造成很难将某个类从项目中隔离出来，难以设置单元测试点。

4.2 解决困难

上述困难均为依赖造成。

1、内部解依赖

对被测代码进行解依赖，强化设计，减少耦合，提高代码可测性。解依赖的过程也即为对代码重构过程，减少类间耦合，制造接口层。常用手段有：虚函数、函数指针、传递参数等方式。而对于难于进行解依赖情况，就要考虑提取分化重写方法。

2、写桩代码模拟外部环境

单元测试不能直接依赖外部环境，必须写桩代码模拟。而外部环境的可模拟性与内部解依赖紧密相关。对于外部的随机性和各种不确定性，桩代码必须尽可能模拟。

3、开辟访问类私有属性通道

有些类方法虽然没有明确返回值，但可能修改类的内部状态，可以通过判断类的私有属性来判定类方法的执行情况。可以给类增加Get()方法或者将私有属性设置为protected。

更重要的是在代码开发期，引入TDD思维，强化设计，提高代码可测性，提高代码的整体质量

最近发现一本<java与模式>,正好再温故一下当年的专业课内容,下面是这几天记的笔记.(并不是系统的讲解书中的内容)
一  综述:
1、不要使用接口定义常量
2、自己少用标志接口
3、不要继承具体类
4、类层次的中间节点应该是接口或者抽象类，叶子是具体类
5、子类应当扩展父类的责任，而不是覆写父类的责任
6、面向接口编程
7、不要滥用继承，组合优先于继承

java中设计不当的类：calendar:作为接口，含有与具体的历法（罗马历法）相关的常量，不能扩展到中国的阴历历法（不符合开闭原则）
                    properies类：滥用继承，继承至hashtable，应当使用聚合

8、笛比特法则：只与自己的直接朋友通信，不与陌生人通信（1）狭义笛比特法则：只与朋友通讯，通过自己的朋友传递间接的调用（2）结合依赖倒转原则修改：不必通过朋友传递间接的调用，通过陌生人的抽象接口调用陌生人的行为（依旧不能与具体的陌生人发生通信）
9、尽量降低类中成员的访问权限，不要设计退化类（类似c中struct）。
        java中的point2D以及Dinmension2D类有这种设计缺陷（不过这种情况问题不大）
10、如果多个具体的产品类没有共同的商业逻辑，就可以把它们抽象到一个接口中，如果有共同的商业逻辑，就把共同的部分抽象到抽象类中，共同的部分尽量向类继承层次的上层移动，以达到复用的目的
二   工厂模式
1、简单工厂模式：参与角色：工厂/抽象产品类/具体产品类

   缺点：添加新产品的时候，虽然产品相关代码符合开闭原则，但对工厂类本身并不符合，需要修改其中的产生产品方法或者添加新的产生方法（工厂里实现的不同造成的修改不同）来支持新的产品类
   退化方式：省略掉工厂角色，抽象产品类担任具体产品类的工厂角色：提供静态的getInstance方法，比如java类库中的DateFormat类，（本人认为这样很不符合开闭原则，父类中出现与具体子类相关的代码，不方便扩展，添加新产品的时候，修改的时候缺点与原简单工厂的工厂角色类似）

2、工厂方法模式：参与角色：抽象工厂类/具体工厂类/抽象产品类/具体产品类
     消除了简单工厂的缺点
3、抽象工厂模式：简单工厂模式与工厂方法模式的结合

4、单例模式：饿汉和懒汉两种，前者将本身对象作为静态私有属性事先生成，后者推迟到调用的时候，后者需要考虑多线程的时候，前面需要加线程安全关键字（注意），java中还是前者为优。
   不要滥用单例，只有系统要求只有一个类的实例的时候才调用
   有的单例可能有状态属性，这就为多例模式提供了可能
   含有私有属性的类作成单例的时候尤其要注意：一是私有属性的线程安全，确实需要的时候可以加线程安全关键字，比如系统中的log类，二是确认这些属性是不是可以所有线程共享的，类似普通类的static
三   各种具体模式（1）
1、建造模式：参与角色4个：指导者、抽象建造对象、具体建造对象、产品
      一个复杂的产品有很多的零部件，就可以使用具体的建造对象来一一构造
2、原始模式：深拷贝、浅拷贝
3、适配器模式：将adaptee类适配成目标接口
4、合成模式：参与角色：composite接口、树枝节点类、树叶节点类
      分成透明式和安全式两种，各有优缺点
      (1)前者将管理子对象的方法放到接口中，这样树型结构中的所有对象都是透明的，都可以统一调用，但是叶节点并没有管理子对象的能力，因此透明但不安全
      (2)后者将管理子对象的方法下放到树枝节点类中，这样安全但不透明
5、装饰模式：继承已有类的接口，提供和已有类相同的方法，并对已有类的功能提供扩展（通过组合已有对象，调用已有对象方法的时候加入新的代码）
      (1)透明的装饰模式（纯粹的装饰模式）：装饰类、被装饰类继承于同一接口，而且装饰类只实现接口的方法，不提供额外方法的实现，调用该类的时候使用接口声明调用（实例化当然还是自己的构造函数），即该类的所有方法都是透明的
      (2)半透明的装饰模式（退化的装饰模式）：装饰类、被装饰类继承于同一接口，装饰类不仅实现接口的方法，还提供额外方法的实现，这样要调用它独特的方法的时候就必须使用它本身来调用，退化到一半装饰模式、一半适配器模式。
四   各种具体模式（2）

1、代理模式：参与角色：代理与真实实体共同的抽象角色、代理角色、真实实体角色
       远程代理：封装对与远程对象复杂的调用通讯过程，象调用本地对象一样
       虚拟代理：真实实体加载时间过长的，使用虚拟代理提供友好的显示方式，一边加载实际的对象
       安全代理：调用真实的对象之前插入权限验证模块
       智能引用代理：调用真实的对象之后调用统计等相关操作模块

2、享元模式：参与对象：建造工厂、抽象享元、具体享元
       分析对象的内蕴与外蕴状态，即不变的私有属性与变化的私有属性。建造工厂使用备忘录模式存储已经建造的对象，建造对象的时候，以参数的形式传递享元对象的内蕴属性。实际调用中，使用传递外部参数的方法使用外蕴变量。

   复合的享元对象组成的对象，不可以整体使用享元模式，但可以单个的享元对象属性使用该模式
   优点：降低内存中的对象  缺点：设计复杂性 

3、门面模式：结构模式。为包含有很多对象的子系统提供统一的操作接口类，所有对该子系统的调用都通过这个类，降低子系统之间调用的复杂度，也符合笛比特法则（一个对象的朋友尽量少，只与朋友说话）

4、桥梁模式：参与角色：抽象化角色、抽象化的具体角色、实现化角色、实现化的具体角色两个有继承等级的对象群，一个对象群对另一个对象群有调用关系的时候使用
        目的：使抽象化与实现化解藕
五   各种具体模式（3）
1、策略：常用于算法族，将算法从依赖的环境中抽象出来形成
2、状态：和策略非常接近，使用于有明显状态变化的时候
3、命令：命令的发起与执行解藕，命令类可以独立演化，有助于做redo undo操作以及记录所执行的命令
4、解释：用于文法的解析
5、迭代子：java中有现成的实现，iterator
6、观察者：常见，类似与模型视图的关系，java中提供了oberver类和observable接口
7、调停者：处理混乱的类交互，抽象出中间类，将类间的交互都通过这个类完成
8、模版：将拥有同一父类的多个具体子类的共同操作提取出来形成抽象模版类
         原则：具体的私有属性应该放到具体类中，抽象类中调用属性通过属性方法而不是直接调用属性
               将私有属性放到具体的类中，才能方便对父类进行多个实现。
         将行为看作划分类的标准，以前我都是将数据模型看作划分类的思想，以后应该重新审视行为在类中的重要作用，特别是在的继承等级中。

void do_msg_type_1_(MsgData &msg)
{
  int id=msg.sessionid;
  if(mapSessions_.find(id)!=mapSessions_.end())
  {
    session *pSession=mapSessions_[id];
    pSession->on_msg_1(msg);
  }
  else
  {
    write_warning_log;
  }
}

如上例所示，session管理类对消息的处理方式必须简单固定，方便可持续维护、扩充。
二 Session的职责
（1）数据结构：每一路连接的业务处理部分，首先有sessionid_标记session本身，其次包含业务处理需要的必须的数据部分，另外最重要的一个数据结构就是状态机了。
（2）状态机。状态机标识session对象的状态，接收外部输入的事件，驱动状态机运行，并作出行为响应。详细见《技术系列之 状态机（一）》和《技术系列之 状态机（二）》，不多说了。
（3）方法。主要分两类：on_msg和do_event。举例如下：

void on_msg(MsgData &msg)
{
    EventData event;
    event.detail=msg.detail;//todo
    fsm.do_event(event);
}
void do_event..(EventData &event)
{
    //change session's data or send msg to other thread or response request or others.. 
}

注意：
1、所有有可能改变session内蕴状态的操作都必须纳入状态机的严格控制，不能存在不通过状态机即可改变session内蕴状态的操作入口。
2、如果两个状态对同样的事件做出同样的反应，并且都迁移到相同的状态，那么这两个是同一个状态。
3、尽可能减少状态的个数。如果两个状态具有严格的时序关系，处理的事件不同并且有严格的时序关系，那么考虑合并这两个状态，防止状态机膨胀。

三 总结：
理解业务部分，先区分消息（Msg)和事件(Event)。
1、消息（Msg)：是指线程之间传递的数据结构，即被投递到线程消息队列中的数据结构。SessionManager主要职责是接收消息，通过消息映射，找到处理该消息的函数，该函数根据消息中携带的sessionid，找到session对象，调用该session的消息处理函数继续后续的处理。
2、事件(Event)：是指被session对象中的状态机处理的数据结构。该数据结构，在session的消息处理函数中通过消息的内容拼凑，之后交给状态机对象处理，状态机对象根据事件类型，通过事件映射，找到处理该事件的函数，继续该事件的处理。
3、代码流程：一般情况下（逻辑控制部分）其它线程不能直接调用session对象，正确的调用方式是发消息SessionManager，SessionManager根据消息找到session对象再进行后续处理。
4、代码要写的足够呆板。
   写出好的系统关键在于对业务的理解，不在于对代码技巧的玩弄。

enum MsgType
{
    MSG_TYPE_1＝65,//64一下预留，用于统一的管理控制
    MSG_TYPE_2,
    ..
    MSG_TYPE_MAX
};
struct Msg
{
    MsgType type;
    MsgData data;
};

switch(msg->type)
{
    case MSG_TYPE_1:
         do_msg_type_1_();
         break;
    case MSG_TYPE_2:
         do_msg_type_2_();
         break;
    ..
    default:
             do_default_msg_();
             break;
}

（2）从代码熵引入查表法
这里引入“代码熵”的概念，用于描述代码的混乱程度。每千行代码中，出现一个“else”，代码熵加1，出现一个“case”，代码熵也加1。如果1k行代码的熵大于7，我们就认为这个代码已经开始变的混乱了。
因此当消息类型不多的时候，使用case是个不错的选择，当处理的消息大于7个并且有扩充趋势的时候，我们就要想另外的办法来代替这种switch...case...的写法。
消除else和case最直接的想法是查表法，使用数组下标标记消息类型，数组保存消息处理方法指针。这里不使用map，查询需要o(lgn)不如数组来的直接，另外设计期间就已明确知道消息的类型以及对应的处理函数，不需要动态增减，也不需要使用vector，直接简单的方法就是定义一个static的数组表。
（3）消息映射
直接的数组展现方式不携带语义，展现方式不直观，维护和扩充都让人头大。这里可用借助宏包裹数组，提供可读的展现方式，如下：

BEGIN_MESSAGE_MAP(SessionManager,SessionMsg)
    ON_MESSAGE(MSG_TYPE_1, SessionManager::do_msg_type_1_)
    ON_MESSAGE(MSG_TYPE_2, SessionManager::do_msg_type_2_)
    
END_MESSAGE_MAP()

如果你熟悉MFC，一定很熟悉这种消息映射的定义方式。这种消息映射的定义方式，从可维护、可读方面比直接的数组更进了一步。宏BEGIN_MESSAGE_MAP、ON_MESSAGE的实现方式不再详写，如果读者实在想象不出来，可以参见《技术系列之 状态机（一）》中的状态机映射宏的定义方式。使用的时候在deal_msg中直接根据消息类型找到数组中的消息处理函数进行处理，如果你认为这样暴露了消息映射背后的数组结构，可以把这个寻找消息处理函数的工作也封装到基类IMsgThread中。
（4）成员函数委托
上面的消息映射宏展开后实际是一个静态数组，而方法do_msg_type_1_/do_msg_type_2_也必须是类的静态成员函数（普通类成员函数指针不能转化为普通函数指针）。通过类的静态成员函数访问类的非静态属性或者方法如下：在消息中携带该类指针handler，处理方法中取到handler指针转换类型，通过指针操作。
当代码中充斥大量通过静态成员函数访问对象私有属性的时候，这无疑是一种丑陋的写法（事实并没有这么严重）。
这里就该boost::function，boost::bind出场了。如果你喜欢，也可以直接写模版实现。也可以参见csdn文章《成员函数指针与高性能的C++委托》
（5）题外话
1、统一的展现方式。
不仅变量的命名需要统一规范，方法的调用逻辑同样需要统一，这可以帮助你明确程序中数据的流向以及保证程序持续的扩充、维护。相对于简单的命名规范，方法调用逻辑的统一更为重要。
以线程类举例说2点（1)其它线程类不能直接调用其它线程的putq方法向对应线程发送消息。正确的做法是调用对应线程类的方法，由该方法负责向本线程发送消息。
(2）发送消息的方法/处理消息的方法职责要明确、命名要统一。
发送消息的方法负责把方法参数转化为消息内容，调用putq发送消息，该方法不得操作本类的任何私有属性。
处理消息的方法负责对消息做出处理、响应。
命名方面，比如发送消息的方法可以以ON_开头，处理消息的方法可以以DO_开头。
这些规范不应该只是规范，而应该是发自内心的需要。当然没有什么规范是必须的，你仍然可以使用你喜欢的或者认为可行的方式，如果你的方法在程序1w行、10w行、50w行的时候，仍能清晰表现程序的数据流向，仍有很好的可维护性、可扩充性。
2、开发领域的烙印。
不多说了。一句话:重要的是思想，不是平台和语言。

struct RTPHeader
{
#if __BYTE_ORDER == __BIG_ENDIAN
  unsigned char v:2; 
  unsigned char p:1;
  unsigned char x:1;
  unsigned char cc:4;
  unsigned char m:1;
  unsigned char pt:7; 
#else
  unsigned char cc:4; 
  unsigned char x:1; 
  unsigned char p:1; 
  unsigned char v:2; 
  unsigned char pt:7;
  unsigned char m:1;
#endif
  unsigned seq:16;
  unsigned tm:32;
  unsigned ssrc:32;
};

收数据到buf，解包过程则是：

Packet *pack=(Packet *)buf

完成解包，读取seq的时候，需要ntohs转化，tm同样要ntohl。
打包相同：

char buf[12];
Packet *pack=(Packet *)buf;
packe->v=2;
.
pack->seq=htons(1);

字符性包解包，则一般是预解包扫描buf，将每个字段的偏移和长度记录下来，等需要的时候在进行内存复制操作（常用的则是立即复制出来）。通常将字段使用枚举定义，比如有字段MAX_FIEDS_NUM个，定义开始位置和偏移结构：

struct FieldLoc
{
 int loc;
 int len;
};

则定义 FieldLoc[MAX_FIEDS_NUM]，准备保存各个字段的偏移和长度。至于扫描字段引起的性能损耗和内存复制引起的性能比较将在后面阐述。
（8）内存池相关、系统调用以及内存复制等的代价这些通用性能部分后面会再有描述。

技术系列，在本人的认知范围内，探讨系统级别的核心技术，文章描述的都是技术本身，最终目的是建立公用的模块库，比如含消息队列的线程模块、状态机模块、定时器模块、对象池模块、log模块、网络层模块、管理接口模块等等。

从个人的角度考虑，开发公用模块，可以加深对系统整体的了解，能有更多的时间去了解新的技术、去认识业务的重要性、去考虑系统划分的合理性，不要陷入技术繁琐细节的泥潭，技术仅仅是工具而已，它们背后的原理都很简单。

从团队的角度考虑，开发公有模块，可以增加系统的可维护性、减少对新员工的培训成本、使具有不同业务的系统在技术细节上呈现一致性，形成开发的可持续性，减少对个人技术的依赖，不会因为某个核心人员的离职而造成后续开发的戛然而止。

公有模块开发导致的后果是减少对个人的依赖，因此有的技术人员可能对开发这些模块产生抵触心理。个人认为，技术是没有边际的，单个人是永远也不会掌握所有技术，单纯的技术也不是正确的职业规划，固步自封只能导致自己技术水平的落后。以开放的心态、职业化的心态去做实际的开发、去交流沟通，最终受益的是自己。

业务系列的文章写点本人接触过的业务，以公有协议为主线，mgcp、sip、rtsp、rtp、rtcp、加密框架等，协议本身、应用场景等，想想可写的东西也不多，和技术一样，都是很少很简单的东西。

系统系列，则从业务的角度出发，描述一些通用系统，也就是纯公有协议业务系统。比如说个媒体负载子系统，该子系统可以独立于信令协议，一个信令系统下可以挂载n个媒体子系统，可协同信令系统完成nat穿透、负载均衡、媒体流加解密等功能，使用私有协议和信令系统通讯，可定时比如60秒发一次负载个数信令到信令系统，一是作为心跳，二是作为负载均衡的依据。再比如一些顶层协议无关的proxy系统设计等。
从团队、公司的角度来考虑，开发公用系统的重要性不言而喻。开发公用系统也即开发工作由项目驱动转化为产品驱动、根据所做一系列项目的固有特点，找出事物的内在规律，合理划分子系统。
开发公用系统，可以降低开发的成本开销，便于公司去开发更多的业务，涉足更多的业务市场，从而形成不断扩大的业务市场，而不是以防守者的姿态，维护自己已有的甚至是逐渐萎缩的业务市场份额。

测试系列。测试团队的开发还是集中于业务层面的测试，白盒测试、稳定性测试还是要研发自己来做。写点自己的测试心得。虽然本blog上的技术文章远多于测试，但个人认为测试的重要性大于技术，不重视测试的研发不是一个好研发，也不会成为一个好研发，顶多是一个夸夸其谈的华而不实者。

团队管理系列，也或许不会写。但从职业发展的角度看，还是应当总结点，在不同的公司感受不同的管理，看看各个公司的相同点不同点，管理的初衷等。团队管理部分，个人看呈现下面几个部分:公司福利/公司制度、项目管理、技术培训、对员工的人文关怀、个人管理等。

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

其中参数n表示监控的所有fd中最大值＋1。
和select模型紧密结合的四个宏，含义不解释了：

FD_CLR(int fd, fd_set *set);
FD_ISSET(int fd, fd_set *set);
FD_SET(int fd, fd_set *set);
FD_ZERO(fd_set *set);

理解select模型的关键在于理解fd_set,为说明方便，取fd_set长度为1字节，fd_set中的每一bit可以对应一个文件描述符fd。则1字节长的fd_set最大可以对应8个fd。
（1）执行fd_set set; FD_ZERO(&set);则set用位表示是0000,0000。
（2）若fd＝5,执行FD_SET(fd,&set);后set变为0001,0000(第5位置为1)
（3）若再加入fd＝2，fd=1,则set变为0001,0011
（4）执行select(6,&set,0,0,0)阻塞等待
（5）若fd=1,fd=2上都发生可读事件，则select返回，此时set变为0000,0011。注意：没有事件发生的fd=5被清空。

基于上面的讨论，可以轻松得出select模型的特点：
（1)可监控的文件描述符个数取决与sizeof(fd_set)的值。我这边服务器上sizeof(fd_set)＝512，每bit表示一个文件描述符，则我服务器上支持的最大文件描述符是512*8=4096。据说可调，另有说虽然可调，但调整上限受于编译内核时的变量值。本人对调整fd_set的大小不太感兴趣，参考http://www.cppblog.com/CppExplore/archive/2008/03/21/45061.html中的模型2（1）可以有效突破select可监控的文件描述符上限。
（2）将fd加入select监控集的同时，还要再使用一个数据结构array保存放到select监控集中的fd，一是用于再select返回后，array作为源数据和fd_set进行FD_ISSET判断。二是select返回后会把以前加入的但并无事件发生的fd清空，则每次开始select前都要重新从array取得fd逐一加入（FD_ZERO最先），扫描array的同时取得fd最大值maxfd，用于select的第一个参数。
（3）可见select模型必须在select前循环array（加fd，取maxfd），select返回后循环array（FD_ISSET判断是否有时间发生）。

下面给一个伪码说明基本select模型的服务器模型：

array[slect_len];
nSock=0;
array[nSock++]=listen_fd;(之前listen port已绑定并listen)
maxfd=listen_fd;
while{
   FD_ZERO(&set);
   foreach (fd in array) 
   {
       fd大于maxfd，则maxfd=fd
       FD_SET(fd,&set)
   }
   res=select(maxfd+1,&set,0,0,0)；
   if(FD_ISSET(listen_fd,&set))
   {
       newfd=accept(listen_fd);
       array[nsock++]=newfd;
            if(--res<=0) continue
   }
   foreach 下标1开始 (fd in array) 
   {
       if(FD_ISSET(fd,&set))
          执行读等相关操作
          如果错误或者关闭，则要删除该fd，将array中相应位置和最后一个元素互换就好，nsock减一
             if(--res<=0) continue

   }
}

二、poll模型
poll原型:

int poll(struct pollfd *ufds, unsigned int nfds, int timeout);
struct pollfd {
                       int fd;           /**//* file descriptor */
                       short events;     /**//* requested events */
                       short revents;    /**//* returned events */
               };

和select相比，两大改进：
（1）不再有fd个数的上限限制，可以将参数ufds想象成栈低指针，nfds是栈中元素个数，该栈可以无限制增长
（2）引入pollfd结构，将fd信息、需要监控的事件、返回的事件分开保存，则poll返回后不会丢失fd信息和需要监控的事件信息，也就省略了select模型中前面的循环操作，返回后的循环仍然不可避免。另每次poll阻塞操作都会自动把上次的revents清空。
poll的服务器模型伪码：

struct pollfd fds[POLL_LEN];
unsigned int nfds=0;
fds[0].fd=server_sockfd;
fds[0].events=POLLIN|POLLPRI;
nfds++;
while{
  res=poll(fds,nfds,-1);
  if(fds[0].revents&(POLLIN|POLLPRI)){执行accept并加入fds中,if(--res<=0)continue}
  循环之后的fds，if(fds[i].revents&(POLLIN|POLLERR )){操作略if(--res<=0)continue}
}

三、epoll模型

epoll阻塞操作的原型：

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)
epoll引入了新的结构epoll_event。
typedef union epoll_data {
                 void *ptr;
                 int fd;
                 __uint32_t u32;
                 __uint64_t u64;
            } epoll_data_t;

            struct epoll_event {
                 __uint32_t events;  /**//* Epoll events */
                 epoll_data_t data;  /**//* User data variable */
            };

与以上模型的优点：
（1）它保留了poll的两个相对与select的优点
（2）epoll_wait的参数events作为出参，直接返回了有事件发生的fd，epoll_wait的返回值既是发生事件的个数，省略了poll中返回之后的循环操作。
（3）不再象select、poll一样将标识符局限于fd，epoll中可以将标识符扩大为指针，大大增加了epoll模型下的灵活性。
epoll的服务器模型伪码：

epollfd=epoll_create(EPOLL_LEN);
epoll_ctl(epollfd,EPOLL_CTL_ADD,server_sockfd,&ev)
struct epoll_event events[EPOLL_MAX_EVENT];
while
{
nfds=epoll_wait(epollfd,events,EPOLL_MAX_EVENT,-1);
循环nfds，是server_sockfd则accept，否则执行响应操作
}

epoll使用中的问题：
（1）epoll_ctl的EPOLL_CTL_DEL操作中，最后一个参数是无意义的，但是在小版本号过低的2.6内核下要求最后一个参数一定非NULL，否则返回失败，并且返回的errno在man epoll_ctl中不存在，因此安全期间，保证epoll_ctl的最后一个参数总非NULLL。
（2）如果一个fd（比如管道）的事件导致了另一个fd2的删除，则必须扫描返回结果集中是否有fd2，有则在结果集中删除，避免冲突。
（3）有文章说epoll在G网环境下性能会低于poll/select，看有些测试，给出的拐点在2w/s并发之后，我本人的工作范围不可能达到这么高的并发，个人在测试性能的时候最大也是取的1w/s的并发，一个是因为系统单进程允许打开的文件描述符最大值，4w的数字太高了，另一个就是我这边服务器的性能达不到那么高的性能，极限1.7w/s的响应，那测试的数据竟然在2w并发的时候还有2w的响应，不知道是什么硬件配置。或许等有了G网的环境，会关注epoll高并发下的性能下降

。
（4）epoll的LT和ET性能的差异，我测试的数据表明两者性能相当，“使用epoll就是为了高性能，就是要使用ET模式”这个说法是站不住脚的。个人倾向于使用LT模式，编程简单、安全。

四、port模型
port则和epoll非常接近，不需要前后的两次扫描，直接返回有事件的结果，可以象epoll一样绑定指针，不同点是
（1）epoll可以返回多个事件，而port一次只返回一个（port_getn可以返回多个，但是在不到指定的n值时，等待直到达到n个）
（2）port返回的结果会自动port_dissociate，如果要再次监控，需要重新port_associate
这个就不多说了。

可以看出select-->poll-->epoll/port的演化路线：
（1）从readset、writeset等分离到 将读写事件集中到统一的结构
（2）从阻塞操作前后的两次循环 到 之后的一次循环  到精确返回有事件发生的fd
（3）从只能绑定fd信息，到可以绑定指针结构信息

五、抽象接口
综合以上多路复用函数的特点，可以进行统一的封装，这里给出我封装的接口，也算是给一个思路：

 virtual int init()=0;
 virtual int wait()=0;
 virtual void * next_result()=0;
 virtual void delete_from_results(void * data)=0;
 virtual void * get_data(void * event)=0;
 virtual int get_event(void * event)=0;
 virtual int add_data(int fd,XPollData * data)=0;
 virtual int delete_data(int fd,XPollData *data)=0;
 virtual int change_data(int fd,XPollData *data)=0;
 virtual int reset_data(int fd,XPollData *data)=0;

使用的时候就是先init，再wait，再循环执行next_result直到空，每个result，使用get_data和get_event挨个处理，如果某个fd引起另一个fd关闭，调delete_from_results（除epoll，其它都直接return），处理完reset_data（select和port用，poll/epoll直接return）。

timeradd(struct timeval *p1,struct timeval *p2,struct timeval *result);
timersub(struct timeval *p1,struct timeval *p2,struct timeval *result);
timercmp(struct timeval *p1,struct timeval *p2,operator op);

对struct timespec同样有timespecadd/timespecsub/timespeccmp，另外还有两者的转换宏，使用函数原型的方式理解就是：

TIMEVAL_TO_TIMESPEC(struct timeval *p1,struct timespec *result);
TIMESPEC_TO_TIMEVAL(struct timespec *p1,struct timeval *result);

如果系统的头文件中找不到，也可以自己实现下，明白这两个结构的细节结构，实现也很简单，这里拿timeradd举例，其它不说了。

#define    timeradd(tvp, uvp, vvp)                        \
    do {                                \
        (vvp)->tv_sec = (tvp)->tv_sec + (uvp)->tv_sec;        \
        (vvp)->tv_usec = (tvp)->tv_usec + (uvp)->tv_usec;    \
        if ((vvp)->tv_usec >= 1000000) {            \
            (vvp)->tv_sec++;                \
            (vvp)->tv_usec -= 1000000;            \
        }                            \
    } while (0)

while(manager->m_state==TIMER_MANAGER_START){
    tm.tv_sec=manager->m_interval.tv_sec;
    tm.tv_usec=manager->m_interval.tv_usec;
    while(select(0,0,0,0,&tm)<0&&errno==EINTR);
    gettimeofday(&now,0);
/**//*加上误差补偿时间*/
    timeradd(&now,&manager－>m_repair,&stand);
    pthread_mutex_lock(&manager->m_mutex);
    TAILQ_FOREACH(item, &(manager->list_), entry_){
/**//*取修正后的时间逐个和定时器中的超时时间点相比，遇到不超时对象则退出扫描*/
        if(timercmp(&item->m_endtime,&stand,<)){
                 if(item->m_func)
                        item->m_func(item,item->m_data);
             if(item->m_type==CTimer::TIMER_ONCE){
                       manager->remove_timer_(item);
                      item->m_state=CTimer::TIMER_TIMEOUT;
                }
            else if(item->m_type==CTimer::TIMER_CIRCLE){
/**//*循环性的要保证链表的顺序性，如要重新插入，保存entry_的原因，是执行新的插入后不要影响当前进行的循环*/
                    tmpTimer.entry_=item->entry_;
                    manager->remove_timer_(item);
                    manager->add_timer_(item);
                   item=&tmpTimer;}
                 }
          else break;
        }
        pthread_mutex_unlock(&manager->m_mutex);
    }

pthread_mutex_t mux=PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond=PTHREAD_COND_INITIALIZER;

//wait操作：
pthread_mutex_lock(&mux);
pthread_cond_wait(&cond,&mux);//睡眠前将内部会执行pthread_mutex_unlock，醒来时内部会执行pthread_mutex_lock
pthread_mutex_unlock(&mux);

//signal操作
pthread_mutex_lock(&mux);
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mux);

（4）sem_t类型的操作。同样:man sem_init 这个系列一般是用不到的，太重量级了，也是最强大的一种。

二、linux2.6内核的线程库。2.6内核的默认安装的是redhat公司的NPTL（原生posix线程库），以前内核安装的是LinuxThreads库，两者的简单介绍可以看http://www.ibm.com/developerworks/cn/linux/l-threading.html。不过对于应用者，分析两者的区别和优劣也没什么大意义。这里特别提下NPTL的futex机制。借助该机制，pthread_mutex的性能大大提高，只要不进入竞争态，进程就不会陷入内核态。这点可以自己写示例程序，通过strace -c 跟踪进程的系统调用得以证实，另外还可以证实总是进入内核态的操作有pthread_cond_signal和sem_post。

三、实用的线程消息队列实现。下面设计一个具有线程消息队列的线程封装类。通过上面的分析，我们可以有如下结论：
（1）减少pthread_cond_signal和sem_post的调用，只在有必要的时候调用；
（2）尽量避免pthread_mutex进入竞争态。增大消息队列的大小，可以有效减少竞态条件的出现。

下面给出一个实用的线程消息队列的实现类，这个类也将是以后《网络模型》文章中用到的线程消息队列类，代码注释请看对私有属性的注释：

class CThreadQueue
{

public:
    CThreadQueue(int queueSize=1024):
        sizeQueue(queueSize),lput(0),lget(0),nFullThread(0),nEmptyThread(0),nData(0)
    {
        pthread_mutex_init(&mux,0);
        pthread_cond_init(&condGet,0);
        pthread_cond_init(&condPut,0);
        buffer=new (void *)[sizeQueue];
    }
    virtual ~CThreadQueue()
    {
        delete[] buffer;
    }
    void * getq()
    {
        void *data;
        pthread_mutex_lock(&mux);
        while(lget==lput&&nData==0)//此处循环判断的原因如下：假设2个线程在getq阻塞，然后两者都被激活，而其中一个线程运行比较块，快速消耗了2个数据，另一个线程醒来的时候已经没有新数据可以消耗了。另一点，man pthread_cond_wait可以看到，该函数可以被信号中断返回，此时返回EINTR。为避免以上任何一点，都必须醒来后再次判断睡眠条件。更正：pthread_cond_wait是信号安全的系统调用，不会被信号中断。
        {
            nEmptyThread++;
            pthread_cond_wait(&condGet,&mux);
            nEmptyThread--;     
        }
            
        data=buffer[lget++];
        nData--;
        if(lget==sizeQueue)
        {
            lget=0;
        }
        if(nFullThread) //必要时才进行signal操作，勿总是signal
        {
            pthread_cond_signal(&condPut);    
        }
        pthread_mutex_unlock(&mux);
        return data;
    }
    void putq(void *data)
    {
        pthread_mutex_lock(&mux);
        while(lput==lget&&nData)
        { 
            nFullThread++;
            pthread_cond_wait(&condPut,&mux);
            nFullThread--;
        }
        buffer[lput++]=data;
        nData++;
        if(lput==sizeQueue)
        {
            lput=0;
        }
        if(nEmptyThread)
        {
            pthread_cond_signal(&condGet);
        }
        pthread_mutex_unlock(&mux);
    }
private:
    pthread_mutex_t mux;
    pthread_cond_t condGet;
    pthread_cond_t condPut;

    void * * buffer;    //循环消息队列
    int sizeQueue;        //队列大小
    int lput;        //location put  放数据的指针偏移
    int lget;        //location get  取数据的指针偏移
    int nFullThread;    //队列满，阻塞在putq处的线程数
    int nEmptyThread;    //队列空，阻塞在getq处的线程数
    int nData;        //队列中的消息个数，主要用来判断队列空还是满
};

下面给出这个线程消息队列的一个使用举例：

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
CThreadQueue queue;//使用的时候给出稍大的CThreadQueue初始化参数，可以减少进入内核态的操作。
void * produce(void * arg)
{
    int i=0;
    pthread_detach(pthread_self());
    while(i++<100)
    {
        queue.putq((void *)i);
    }
}
void *consume(void *arg)
{
    int data;
    while(1)
    {
        data=(int)(queue.getq());
        printf("data=%d\n",data)
    }
}
int main()
{    pthread_t pid;
    int i=0;

    while(i++<3)
        pthread_create(&pid,0,produce,0);
    i=0;
    while(i++<3)
        pthread_create(&pid,0,consume,0);
    sleep(300);
}

#include <boost/pool/pool.hpp>
typedef struct student_st
{
   char name[10];
   int age;
}CStudent;
int main()
{
   boost::pool<> student_pool(sizeof(CStudent));
   CStudent * const obj=(CStudent *)student_pool.malloc();
   student_pool.free(obj);
   return 0;
}

    pool的模版参数只有一个分配子类型，boost提供了两种default_user_allocator_new_delete/default_user_allocator_malloc_free，指明申请释放内存的时候使用new/delete，还是malloc/free，默认是default_user_allocator_new_delete。构造函数有2个参数：nrequested_size,nnext_size。nrequested_size是block的大小（因为void*保存序号，因此boost内置了block的最小值，nrequested_size过小则取内置值），nnext_size是simple_segregated_storage中内存不足的时候，申请的block数量，默认是32。最全面的实例化pool类似这样：boost::pool<boost::default_user_allocator_malloc_free> student_pool(sizeof(CStudent),255);
    pool提供的函数主要有：

malloc/free	基于add_block/malloc/free实现，高效
ordered_malloc/ordered_free	基于add_ordered_block/malloc/ordered_free实现，在pool中无任何意义，切勿使用。
release_memory/purge_memory	前者释放池中未使用内存，后者释放池中所有内存。另池析构也会释放内存

2）object_pool
对象内存池，这是最失败的一个内存池设计。

#include <boost/pool/object_pool.hpp>

class A{
public:
   A():data_(0){}
private:
   int data_;
};
int main()
{
   boost::object_pool<A> obj_pool;
   A *const pA=obj_pool.construct();
   obj_pool.destroy(pA);
   return 0;
}

    object_pool继承至pool，有两个模版参数，第一个就是对象类型，第二个是分配子类型，默认同pool是default_user_allocator_new_delete。构造函数参数只有nnext_size，意义以及默认值同pool。最全面的实例化object_pool类似这样：boost::pool<A,boost::default_user_allocator_malloc_free> obj_pool(255);
object_pool提供的函数主要有（继承至父类的略）：

malloc/free	复写pool的malloc/free，add_ordered_block/malloc/ordered_free实现
construct/destroy	基于本类的malloc/free实现，额外调用默认构造函数和默认析构函数。
~object_pool	单独拿出这个说下，若析构的时候有对象未被destroy，可以检测到，释放内存前对其执行destroy

    为什么boost::object_pool要设计成这样？能调用构造函数和析构函数显然不是boost::object_pool类设计的出发点，因为构造函数只能执行默认构造函数（首次发表错误：可以调用任意的构造函数，参见代码文件：boost/pool/detail/pool_construct.inc和boost/pool/detail/pool_construct_simple.inc，感谢eXile指正），近似于无，它的重点是内存释放时候的清理工作，这个工作默认的析构函数就足够了。apr_pool内存池中就可以注册内存清理函数，在释放内存的时刻执行关闭文件描述符、关闭socket等操作。boost::object_pool也想实现同样的功能，因此设计了destroy这个函数，而同时为了防止用户遗漏掉这个调用，而又在内存池析构的时候进行了检测回收。为了这个目的而又不至于析构object_pool的时间复杂度是O(n平方），boost::object_pool付出了沉重的代价，在每次的destoy都执行排序功能，时间复杂度O(n),最后析构的时间复杂度是O(n)，同样为了这个目的，从simple_segregated_storage增加了add_ordered_block/ordered_free，pool增加了ordered_malloc/ordered_free等累赘多余的功能。
    基于上面讨论的原因，boost::object_pool被设计成了现在的样子，成了一个鸡肋类。类的设计者似乎忘记了内存池使用的初衷，忘记了内存池中内存申请释放的频率很高，远远大于内存池对象的析构。如果你依然想使用类似于此的内存清理功能，可以在boost::object_pool上修改，不复写malloc/free即可，重写object_pool的析构，简单释放内存就好，因此析构object_pool前不要忘记调用destroy，这也是使用placement new默认遵守的规则，或者保持以前的析构函数，牺牲析构时的性能。placement new的作用是为已经申请好的内存调用构造函数，使用流程为（1）申请内存buf（2）调用placement new：new(buf)construtor()（3）调用析构destructor()（4）释放内存buf。#include<new>可以使用placement new。
3）singleton_pool
pool的加锁版本。

#include <boost/pool/singleton_pool.hpp>
typedef struct student_st
{
   char name[10];
   int age;
}CStudent;
typedef struct singleton_pool_tag{}singleton_pool_tag;
int main()
{
   typedef boost::singleton_pool<singleton_pool_tag,sizeof(CStudent)>  global;
   CStudent * const df=(CStudent *)global::malloc();
   global::free(df);
   return 0;
}

    singleton_pool为单例类，是对pool的加锁封装，适用于多线程环境，其中所有函数都是静态类型。它的模版参数有5个，tag：标记而已，无意义；RequestedSize：block的长度；UserAllocator：分配子，默认还是default_user_allocator_new_delete；Mutex：锁机制，默认值最终依赖于系统环境，linux下是pthread_mutex，它是对pthread_mutex_t的封装；NextSize：内存不足的时候，申请的block数量，默认是32。最全面的使用singleton_pool类似这样：typedef boost::singleton_pool<singleton_pool_tag,sizeof(CStudent),default_user_allocator_new_delete,details::pool::default_mutex,200>  global;
    它暴露的函数和pool相同。
4）pool_allocator/fast_pool_allocator
    stl::allocator的替换方案。两者都是基于singleton_pool实现，实现了stl::allocator要求的接口规范。两者的使用相同，区别在于pool_allocator的实现调用ordered_malloc/ordered_free，fast_pool_allocator的实现调用malloc/free，因此推荐使用后者。

#include <boost/pool/pool_alloc.hpp>
#include <vector>
typedef struct student_st
{
 char name[10];
 int age;
}CStudent;

int main()
{
  std::vector<CStudent *,boost::fast_pool_allocator<CStudent *> > v(8);
  CStudent *pObj=new CStudent();
  v[1]=pObj;
  boost::singleton_pool<boost::fast_pool_allocator_tag,sizeof(CStudent *)>::purge_memory(); 
  return 0;
}

    fast_pool_allocator的模版参数有四个：类型，分配子，锁类型，内存不足时的申请的block数量，后三者都有默认值，不再说了。它使用的singleton_pool的tag是boost::fast_pool_allocator_tag。
评价：boost::pool小巧高效，多多使用，多线程环境下使用boost::singleton_pool，不要使用两者的ordered_malloc/ordered_free函数。boost::object_pool不建议使用，可以改造后使用。pool_allocator/fast_pool_allocator推荐使用后者。

#include "loki/SmallObj.h"
class Small:public  Loki::SmallObject<>//继承SmallObject即可，所有都使用默认策略
{
public:
 Small(int data):data_(data){}
private:
 int data_;
};
int main()
{
 Small *obj=new Small(8);
 delete obj;
}

使用valgrind执行可以证实new一个obj和多new几次，申请的内存都是4192。可以看出loki在使用层面非常简单。
    loki的内存池分4层,从低向上依次是chunk、FixedAllocator、SmallObjAllocator、SmallObject。
1）chunk：每个chunk管理一定数量（最大255，char型保存）的block，每个chunk中block的申请和释放，时间复杂度都是o(1)，非常快，实现算法非常精巧，boost::pool中也是采用的相同算法。
    这里简单说下这个算法：首次申请一块连续内存，pdata_指向该内存基址，依据block大小，划分成多个连续的block，每个block开头的第一个字节保存该block的顺序号，第一个是1，第二个是2，依次类推。另有一字节变量firstAvailableBlock_存储上次分配出的block序号，开始是0。
    分配block：返回pdata_ +firstAvailableBlock_*blocksize，同时firstAvailableBlock_赋值为该块的序列号。
    回收block：block指针假设为pblock，该块序列号赋值为firstAvailableBlock_，firstAvailableBlock_赋值为（pblock-pdata_ ）/blocksize即可。
2）FixedAllocator：chunk中的block上限是255，不具有通用性，因此封装了一层，称为FixedAllocator，它保存了一个vector<chunk>，消除了单个chunk中block数目的上限限制。
   FixedAllocator中的block申请：FixedAllocator中保存活动的chunk（上次有空闲空间的chunk），申请block的时候如果活动chunk有空闲快，直接申请，否则扫描vector，时间复杂度o(N),同时更新活动chunk。
   FixedAllocator中的回收block：简单想，给定block回收到FixedAllocator，自然要扫描vector，以确认block属于哪个chunk，以便chunk回收。实际实现的时候，Loki针对应用场景进行了优化，一般使用都是批量使用，回收一般和申请顺序相同或者相反，因此FixedAllocator保存上次回收block的chunk指针，每次回收优先匹配这个chunk，匹配不上则以该chunk为中心，向两侧chunk顺序检测。
   FixedAllocator带来的优点：上文提到的消除了block的上限限制。另一方面，可以以chunk为单位，把内存归还给操作系统。实际实现中防止刚释放的内存立即又被申请，是存在两个空闲chunk的时候才回收一个。这个特点，这里暂时归结为优点吧。实际使用中，回收多余内存个人认为是个缺点，意义并不是很大。
   FixedAllocator带来的缺点：很明显，就是申请回收block的时间复杂度。
3）SmallObjAllocator：截至到FixedAllocator层面blocksize都是定长。因此封装一层适用于任意长度的内存申请。SmallObjAllocator保存了一个FixedAllocator的数组pool_，存储拥有不同block长度的FixedAllocator。《Modern C++ Design》中描述该数组下标和存储的FixedAllocator的block长度无直接关系，从SmallObjAllocator申请以及回收block的时候二分查找找到对应的FixedAllocator再调用相应FixedAllocator的申请或者回收。当前最新版本的loki，已经抛弃了这种做法。当前SmallObjAllocator的构造函数有3个参数：chunksize，maxblocksize，alignsize。数组元素个数取maxblocksize除以alignsize的向上取整。每个FixedAllocator中实际的blocksize是（下标＋1）*alignsize。
     SmallObjAllocator中block申请：依据block和alignsize的商直接取到数组pool_下标，使用相应的FixedAllocator申请。
     SmallObjAllocator中回收block：根据block和alignsize的商直接找到相应的FixedAllocator回收。
     优点：差异化各种长度的对象申请，增强了易用性。
     缺点：《Modern C++ Design》中描述增加扫描的时间复杂度，当前版本的loki浪费内存。这也是进一步封装，屏蔽定长申请的细节，带来的负面效应。
4）SmallObject。暴露给外部使用的一层。该层面秉承了《Modern C++ Design》开始引入的以设计策略类为最终目的，让用户在编译期选择设计策略，而不是提供框架限制用户的设计。这也是引入模版的一个层面。当前版本SmallObject有6个模版参数，第一个是线程策略，紧接着的三个正好是SmallObjAllocator层面的三个构造参数，下面的一个生存期策略，最后的是锁方式。
    这里说下SmallObjAllocator层面的三个默认参数值，分别是4096，256，4。意味着SmallObjAllocator层面有数组（256+4-1)/4=64个，数组存储的FixedAllocator中的chunksize一般都是4096（当4096<=blocksize*255时候）字节（第一个chunk的申请推迟到首次使用的时候），各FixedAllocator中的chunk的blocksize依次是4、8......256，大于256字节的内存申请交给系统的malooc/new管理，数组中FixedAllocator中单个chunk中的blocknum依次是4096/4=824>255取255、255......4096/256=16。如果这不能满足需求，请调用的时候显式赋值。
    当前loki提供了三种线程策略：

SingleThreaded	单线程
ObjectLevelLockable	对象级别，一个对象一个锁
ClassLevelLockable	类级别，一个类一个锁，该类的所有对象共用该锁

目前只提供了一种锁机制：Mutex
它的基类SmallObjectBase复写了new/delete操作子，因此直接继承SmallObject就可以象普通的类一样new/delete，并且从内存池分配内存。
    SmalObject中block申请和释放都从一个全局的SmallObjAllocator单例进行。
评价：chunk层面限制了上限个数，导致了FixedAllocator层面出现，造成申请回收时间复杂度的提高，而以chunk为单位回收内存，在内存池的使用场景下意义并不是很大。SmallObjAllocator为了差异化变长内存的申请，对FixedAllocator进一步封装，引入了内存的浪费，不如去掉这个层面，直接提供给用户层面定长的接口。另一方面，loki已经进行了不少优化，尽可能让block申请释放的时间复杂度在绝大多数情况下都是O(1),而SmallObjAllocator中内存的浪费可以根据alignsize调整，即便是极端情况下，loki将chunk归还给系统又被申请出来，根据chunk中block的最大值看，也比不使用内存池的情况动态申请释放内存的次数减少了1/255。因此，loki是一个非常不错的小巧的内存池。