### NDC ###

首先我们先了解一下log4cplus中嵌入诊断上下文（Nested Diagnostic Context），即NDC。对log系统而言，
当输入源可能不止一个，而只有一个输出时，往往需要分辩所要输出消息的来源，比如服务器处理来自不同
客户端的消息时就需要作此判断，NDC可以为交错显示的信息打上一个标记(stamp)， 使得辨认工作看起来
比较容易些，呵呵。这个标记是线程特有的，利用了线程局部存储机制，称为线程私有数据（Thread-specific
 Data，或TSD）。 看了一下源代码，相关定义如下，包括定义、初始化、获取、设置和清除操作：

linux pthread

				
#   define LOG4CPLUS_THREAD_LOCAL_TYPE pthread_key_t*
#   define LOG4CPLUS_THREAD_LOCAL_INIT ::log4cplus::thread::createPthreadKey()
#   define LOG4CPLUS_GET_THREAD_LOCAL_VALUE( key ) pthread_getspecific(*key)
#   define LOG4CPLUS_SET_THREAD_LOCAL_VALUE( key, value ) pthread_setspecific(*key, value)
#   define LOG4CPLUS_THREAD_LOCAL_CLEANUP( key ) pthread_key_delete(*key)

win32

#   define LOG4CPLUS_THREAD_LOCAL_TYPE DWORD
#   define LOG4CPLUS_THREAD_LOCAL_INIT TlsAlloc()
#   define LOG4CPLUS_GET_THREAD_LOCAL_VALUE( key ) TlsGetValue(key)
#   define LOG4CPLUS_SET_THREAD_LOCAL_VALUE( key, value ) \
       TlsSetValue(key, static_cast(value))
#   define LOG4CPLUS_THREAD_LOCAL_CLEANUP( key ) TlsFree(key)

				
使用起来比较简单，在某个线程中：

    NDC& ndc = log4cplus::getNDC();
    ndc.push("ur ndc string");
    LOG4CPLUS_DEBUG(logger, "this is a NDC test");

    ... ...
    
    ndc.pop();
    
    ... ...
    
    LOG4CPLUS_DEBUG(logger, "There should be no NDC...");
    ndc.remove();
    
当设定输出格式(Layout)为TTCCLayout时，输出如下：

10-21-04 21:32:58, [3392] DEBUG test  - this is a NDC test
10-21-04 21:32:58, [3392] DEBUG test <> - There should be no NDC...

也可以在自定义的输出格式中使用NDC(用%x) ，比如：

    ... ...
    
    std::string pattern = "NDC:[%x]  - %m %n";
    std::auto_ptr _layout(new PatternLayout(pattern));

    ... ...
    
    LOG4CPLUS_DEBUG(_logger, "This is the FIRST log message...")
    NDC& ndc = log4cplus::getNDC();
    ndc.push("ur ndc string");
    LOG4CPLUS_WARN(_logger, "This is the SECOND log message...")
    ndc.pop();
    ndc.remove();
    
    ... ...
    
输出如下：

NDC:[]  - This is the FIRST log message...
NDC:[ur ndc string]  - This is the SECOND log message...

				
另外一种更简单的使用方法是在线程中直接用NDCContextCreator：

    NDCContextCreator _first_ndc("ur ndc string");
    LOG4CPLUS_DEBUG(logger, "this is a NDC test")
    
不必显式地调用push/pop了，而且当出现异常时，能够确保push与pop的调用是匹配的。

    
### 线程 ###

线程是log4cplus中的副产品， 而且仅作了最基本的实现，使用起来也异常简单，只要且必须要
在派生类中重载run函数即可：

class TestThread : public AbstractThread
{
public:

    virtual void run();

};

				
void TestThread::run()
{
    /* do sth. */
    ... ...

}

log4cplus的线程没有考虑同步、死锁，有互斥，实现线程切换的小函数挺别致的：

void log4cplus::thread::yield()
{
#if defined(LOG4CPLUS_USE_PTHREADS)
    ::sched_yield();
#elif defined(LOG4CPLUS_USE_WIN32_THREADS)
    ::Sleep(0);
#endif
}

				
### 套接字 ###

套接字也是log4cplus中的副产品，在namespace log4cplus::helpers中，实现了C/S方式的日志记录。

1. 客户端程序需要做的工作：

/* 定义一个SocketAppender类型的挂接器 */
SharedAppenderPtr _append(new SocketAppender(host, 8888, "ServerName"));

/* 把_append加入到logger中 */
Logger::getRoot().addAppender(_append);

/*  SocketAppender类型不需要Layout, 直接调用宏就可以将信息发往loggerServer了 */
LOG4CPLUS_INFO(Logger::getRoot(), "This is a test: ")

				
【注】 这里对宏的调用其实是调用了SocketAppender::append，里面有一个数据传输约定，即先发送
一个后续数据的总长度，然后再发送实际的数据：

    ... ...

    SocketBuffer buffer = convertToBuffer(event, serverName);
    SocketBuffer msgBuffer(LOG4CPLUS_MAX_MESSAGE_SIZE);

    msgBuffer.appendSize_t(buffer.getSize());
    msgBuffer.appendBuffer(buffer);
   
    ... ...

				
2. 服务器端程序需要做的工作：

/* 定义一个ServerSocket */
ServerSocket serverSocket(port);

/* 调用accept函数创建一个新的socket与客户端连接 */
Socket sock = serverSocket.accept();

				
此后即可用该sock进行数据read/write了,形如：

SocketBuffer msgSizeBuffer(sizeof(unsigned int));

if(!clientsock.read(msgSizeBuffer))
{
    return;
}

unsigned int msgSize = msgSizeBuffer.readInt();

SocketBuffer buffer(msgSize);

if(!clientsock.read(buffer))
{
    return;
}

为了将读到的数据正常显示出来，需要将SocketBuffer存放的内容转换成InternalLoggingEvent格式：

spi::InternalLoggingEvent event = readFromBuffer(buffer);

然后输出：
Logger logger = Logger::getInstance(event.getLoggerName());
logger.callAppenders(event);

				
【注】 read/write是按照阻塞方式实现的，意味着对其调用直到满足了所接收或发送的个数才返回。

				
### 如何将log记录到文件 ###

我们在例5中给出了一个将log记录到文件的例子，用的是FileAppender类实现的，log4cplus提供了三个类用于
文件操作，它们是FileAppender类、RollingFileAppender类、DailyRollingFileAppender类。

1. FileAppender类

实现了基本的文件操作功能，构造函数如下：

FileAppender(const log4cplus::tstring& filename,
                     LOG4CPLUS_OPEN_MODE_TYPE mode = LOG4CPLUS_FSTREAM_NAMESPACE::ios::trunc,
                     bool immediateFlush = true);
                     
filename       : 文件名
mode           : 文件类型，可选择的文件类型包括app、ate、binary、in、out、trunc，因为实际上只是对
                 stl的一个简单包装，呵呵，这里就不多讲了。缺省是trunc，表示将先前文件删除。
immediateFlush ：缓冲刷新标志，如果为true表示每向文件写一条记录就刷新一次缓存，否则直到FileAppender
                 被关闭或文件缓存已满才更新文件，一般是要设置true的，比如你往文件写的过程中出现
                 了错误（如程序非正常退出），即使文件没有正常关闭也可以保证程序终止时刻之前的所有
                 记录都会被正常保存。

FileAppender类的使用情况请参考例5，这里不再赘述。

				
2. RollingFileAppender类

构造函数如下：
log4cplus::RollingFileAppender::RollingFileAppender(const log4cplus::tstring& filename,
                                                    long maxFileSize,
                                                    int maxBackupIndex,
                                                    bool immediateFlush)

filename       : 文件名
maxFileSize    : 文件的最大尺寸
maxBackupIndex : 最大记录文件数
immediateFlush : 缓冲刷新标志
                                                    
RollingFileAppender类可以根据你预先设定的大小来决定是否转储，当超过该大小，后续log信息会另存到新
文件中，除了定义每个记录文件的大小之外，你还要确定在RollingFileAppender类对象构造时最多需要多少个
这样的记录文件(maxBackupIndex+1)，当存储的文件数目超过maxBackupIndex+1时，会删除最早生成的文件，
保证整个文件数目等于maxBackupIndex+1。然后继续记录，比如以下代码片段：

    ... ...
    
    #define LOOP_COUNT 200000
    
    SharedAppenderPtr _append(new RollingFileAppender("Test.log", 5*1024, 5));
    _append->setName("file test");
    _append->setLayout( std::auto_ptr(new TTCCLayout()) );
    Logger::getRoot().addAppender(_append);

    Logger root = Logger::getRoot();
    Logger test = Logger::getInstance("test");
    Logger subTest = Logger::getInstance("test.subtest");

    for(int i=0; i    {
        NDCContextCreator _context("loop");
        LOG4CPLUS_DEBUG(subTest, "Entering loop #" << i)
    }
    
    ... ...
    

运行结果：

运行后会产生6个输出文件，Test.log、Test.log.1、Test.log.2、Test.log.3、Test.log.4、Test.log.5
其中Test.log存放着最新写入的信息，而最后一个文件中并不包含第一个写入信息，说明已经被不断更新了。
需要指出的是，这里除了Test.log之外，每个文件的大小都是200K,而不是我们想像中的5K，这是因为
log4cplus中隐含定义了文件的最小尺寸是200K，只有大于200K的设置才生效，<= 200k的设置都会被认为是
200K.

				
3. DailyRollingFileAppender类

构造函数如下：
DailyRollingFileAppender::DailyRollingFileAppender(const log4cplus::tstring& filename,
                                                   DailyRollingFileSchedule schedule,
                                                   bool immediateFlush,
                                                   int maxBackupIndex)
                                                   
filename       : 文件名
schedule       : 存储频度
immediateFlush : 缓冲刷新标志
maxBackupIndex : 最大记录文件数

DailyRollingFileAppender类可以根据你预先设定的频度来决定是否转储，当超过该频度，后续log信息会另存
到新文件中，这里的频度包括：MONTHLY（每月）、WEEKLY（每周）、DAILY（每日）、TWICE_DAILY（每两天）、
HOURLY（每时）、MINUTELY（每分）。maxBackupIndex的含义同上所述，比如以下代码片段：

    ... ...
    
    SharedAppenderPtr _append(new DailyRollingFileAppender("Test.log", MINUTELY, true, 5));
    _append->setName("file test");
    _append->setLayout( std::auto_ptr(new TTCCLayout()) );
    Logger::getRoot().addAppender(_append);

    Logger root = Logger::getRoot();
    Logger test = Logger::getInstance("test");
    Logger subTest = Logger::getInstance("test.subtest");

    for(int i=0; i    {
        NDCContextCreator _context("loop");
        LOG4CPLUS_DEBUG(subTest, "Entering loop #" << i)
    }
    
    ... ...

				
运行结果：

运行后会以分钟为单位，分别生成名为Test.log.2004-10-17-03-03、Test.log.2004-10-17-03-04和
Test.log.2004-10-17-03-05这样的文件。

需要指出的是，刚看到按照频度（如HOURLY、MINUTELY）转储这样的概念，以为log4cplus提供了内部定时器，
感觉很奇怪，因为日志系统不应该主动记录，而loging事件总是应该被动触发的啊。仔细看了源代码后才知道
这里的"频度"并不是你写入文件的速度，其实是否转储的标准并不依赖你写入文件的速度，而是依赖于写入
的那一时刻是否满足了频度条件，即是否超过了以分钟、小时、周、月为单位的时间刻度，如果超过了就另存。

本部分详细介绍log信息的几种文件操作方式，下面将重点介绍一下如何有选择地控制log信息的输出。

				
### 优先级控制 ###

在研究LogLevelManager之前，首先介绍一下log4cplus中logger的存储机制，在log4cplus中，所有
logger都通过一个层次化的结构（其实内部是hash表）来组织的，有一个Root级别的logger,可以通
过以下方法获取：

    Logger root = Logger::getRoot();
    
用户定义的logger都有一个名字与之对应，比如：

    Logger test = Logger::getInstance("test");
    
可以定义该logger的子logger:

    Logger subTest = Logger::getInstance("test.subtest");
    
注意Root级别的logger只有通过getRoot方法获取，Logger::getInstance("root")获得的是它的
子对象而已。有了这些具有父子关系的logger之后可分别设置其LogLevel,比如：

root.setLogLevel( ... );
Test.setLogLevel( ... );
subTest.setLogLevel( ... );

				
logger的这种父子关联性会体现在优先级控制方面，log4cplus将输出的log信息按照LogLevel
（从低到高）分为：

NOT_SET_LOG_LEVEL (   -1) ：接受缺省的LogLevel，如果有父logger则继承它的LogLevel
ALL_LOG_LEVEL     (    0) ：开放所有log信息输出
TRACE_LOG_LEVEL   (    0) ：开放trace信息输出(即ALL_LOG_LEVEL)
DEBUG_LOG_LEVEL   (10000) ：开放debug信息输出
INFO_LOG_LEVEL    (20000) ：开放info信息输出
WARN_LOG_LEVEL    (30000) ：开放warning信息输出
ERROR_LOG_LEVEL   (40000) ：开放error信息输出
FATAL_LOG_LEVEL   (50000) ：开放fatal信息输出
OFF_LOG_LEVEL     (60000) ：关闭所有log信息输出

LogLevelManager负责设置logger的优先级，各个logger可以通过setLogLevel设置自己的优先级，
当某个logger的LogLevel设置成NOT_SET_LOG_LEVEL时，该logger会继承父logger的优先级，另外，
如果定义了重名的多个logger, 对其中任何一个的修改都会同时改变其它logger,我们举例说明：

〖例6〗

#include "log4cplus/logger.h"
#include "log4cplus/consoleappender.h"
#include "log4cplus/loglevel.h"
#include <iostream>

using namespace std;
using namespace log4cplus;

int main()
{
    SharedAppenderPtr _append(new ConsoleAppender());
    _append->setName("test");
    Logger::getRoot().addAppender(_append);
    Logger root = Logger::getRoot();

    Logger test = Logger::getInstance("test");
    Logger subTest = Logger::getInstance("test.subtest");
    LogLevelManager& llm = getLogLevelManager();

    cout << endl << "Before Setting, Default LogLevel" << endl;
    LOG4CPLUS_FATAL(root, "root: " << llm.toString(root.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test: " << llm.toString(test.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test.subtest: " << llm.toString(subTest.getChainedLogLevel()))

    cout << endl << "Setting test.subtest to WARN" << endl;
    subTest.setLogLevel(WARN_LOG_LEVEL);
    LOG4CPLUS_FATAL(root, "root: " << llm.toString(root.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test: " << llm.toString(test.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test.subtest: " << llm.toString(subTest.getChainedLogLevel()))

    cout << endl << "Setting test.subtest to TRACE" << endl;
    test.setLogLevel(TRACE_LOG_LEVEL);
    LOG4CPLUS_FATAL(root, "root: " << llm.toString(root.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test: " << llm.toString(test.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test.subtest: " << llm.toString(subTest.getChainedLogLevel()))

    cout << endl << "Setting test.subtest to NO_LEVEL" << endl;
    subTest.setLogLevel(NOT_SET_LOG_LEVEL);
    LOG4CPLUS_FATAL(root, "root: " << llm.toString(root.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test: " << llm.toString(test.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test.subtest: " << llm.toString(subTest.getChainedLogLevel()) << '\n')

    cout << "create a logger test_bak, named \"test_\", too. " << endl;
    Logger test_bak = Logger::getInstance("test");
    cout << "Setting test to INFO, so test_bak also be set to INFO" << endl;
    test.setLogLevel(INFO_LOG_LEVEL);
    LOG4CPLUS_FATAL(root, "test: " << llm.toString(test.getChainedLogLevel()))
    LOG4CPLUS_FATAL(root, "test_bak: " << llm.toString(test_bak.getChainedLogLevel()))

    return 0;
}

输出结果：

Before Setting, Default LogLevel
FATAL - root: DEBUG
FATAL - test: DEBUG
FATAL - test.subtest: DEBUG

Setting test.subtest to WARN
FATAL - root: DEBUG
FATAL - test: DEBUG
FATAL - test.subtest: WARN

Setting test.subtest to TRACE
FATAL - root: DEBUG
FATAL - test: TRACE
FATAL - test.subtest: WARN

Setting test.subtest to NO_LEVEL
FATAL - root: DEBUG
FATAL - test: TRACE
FATAL - test.subtest: TRACE

create a logger test_bak, named "test_", too.
Setting test to INFO, so test_bak also be set to INFO
FATAL - test: INFO
FATAL - test_bak: INFO

				
下面的例子演示了如何通过设置LogLevel来控制用户的log信息输出：

〖例7〗

#include "log4cplus/logger.h"
#include "log4cplus/consoleappender.h"
#include "log4cplus/loglevel.h"
#include <iostream>

using namespace std;
using namespace log4cplus;

void ShowMsg(void)
{
    LOG4CPLUS_TRACE(Logger::getRoot(),"info")
    LOG4CPLUS_DEBUG(Logger::getRoot(),"info")
    LOG4CPLUS_INFO(Logger::getRoot(),"info")
    LOG4CPLUS_WARN(Logger::getRoot(),"info")
    LOG4CPLUS_ERROR(Logger::getRoot(),"info")
    LOG4CPLUS_FATAL(Logger::getRoot(),"info")
}

int main()
{
    SharedAppenderPtr _append(new ConsoleAppender());
    _append->setName("test");
    _append->setLayout(std::auto_ptr(new TTCCLayout()));
    Logger root = Logger::getRoot();
    root.addAppender(_append);

    cout << endl << "all-log allowed" << endl;
    root.setLogLevel(ALL_LOG_LEVEL);
    ShowMsg();

    cout << endl << "trace-log and above allowed" << endl;
    root.setLogLevel(TRACE_LOG_LEVEL);
    ShowMsg();

    cout << endl << "debug-log and above allowed" << endl;
    root.setLogLevel(DEBUG_LOG_LEVEL);
    ShowMsg();

    cout << endl << "info-log and above allowed" << endl;
    root.setLogLevel(INFO_LOG_LEVEL);
    ShowMsg();

    cout << endl << "warn-log and above allowed" << endl;
    root.setLogLevel(WARN_LOG_LEVEL);
    ShowMsg();

    cout << endl << "error-log and above allowed" << endl;
    root.setLogLevel(ERROR_LOG_LEVEL);
    ShowMsg();

    cout << endl << "fatal-log and above allowed" << endl;
    root.setLogLevel(FATAL_LOG_LEVEL);
    ShowMsg();

    cout << endl << "log disabled" << endl;
    root.setLogLevel(OFF_LOG_LEVEL);
    ShowMsg();

    return 0;
}

输出结果：

all-log allowed
10-17-04 10:11:40,587 [1075298944] TRACE root <> - info
10-17-04 10:11:40,590 [1075298944] DEBUG root <> - info
10-17-04 10:11:40,591 [1075298944] INFO root <> - info
10-17-04 10:11:40,591 [1075298944] WARN root <> - info
10-17-04 10:11:40,592 [1075298944] ERROR root <> - info
10-17-04 10:11:40,592 [1075298944] FATAL root <> - info

trace-log and above allowed
10-17-04 10:11:40,593 [1075298944] TRACE root <> - info
10-17-04 10:11:40,593 [1075298944] DEBUG root <> - info
10-17-04 10:11:40,594 [1075298944] INFO root <> - info
10-17-04 10:11:40,594 [1075298944] WARN root <> - info
10-17-04 10:11:40,594 [1075298944] ERROR root <> - info
10-17-04 10:11:40,594 [1075298944] FATAL root <> - info

debug-log and above allowed
10-17-04 10:11:40,595 [1075298944] DEBUG root <> - info
10-17-04 10:11:40,595 [1075298944] INFO root <> - info
10-17-04 10:11:40,596 [1075298944] WARN root <> - info
10-17-04 10:11:40,596 [1075298944] ERROR root <> - info
10-17-04 10:11:40,596 [1075298944] FATAL root <> - info

info-log and above allowed
10-17-04 10:11:40,597 [1075298944] INFO root <> - info
10-17-04 10:11:40,597 [1075298944] WARN root <> - info
10-17-04 10:11:40,597 [1075298944] ERROR root <> - info
10-17-04 10:11:40,598 [1075298944] FATAL root <> - info

warn-log and above allowed
10-17-04 10:11:40,598 [1075298944] WARN root <> - info
10-17-04 10:11:40,598 [1075298944] ERROR root <> - info
10-17-04 10:11:40,599 [1075298944] FATAL root <> - info

error-log and above allowed
10-17-04 10:11:40,599 [1075298944] ERROR root <> - info
10-17-04 10:11:40,600 [1075298944] FATAL root <> - info

fatal-log and above allowed
10-17-04 10:11:40,600 [1075298944] FATAL root <> - info

log disabled

用户也可以自行定义LogLevel，操作比较简单，首先要定义LEVEL值，比如HELLO_LOG_LEVEL定义如下：

/* DEBUG_LOG_LEVEL  < HELLO_LOG_LEVEL < INFO_LOG_LEVEL */
const LogLevel HELLO_LOG_LEVEL = 15000;

然后定义以下宏即可：

/* define MACRO LOG4CPLUS_HELLO */
#define LOG4CPLUS_HELLO(logger, logEvent) \
    if(logger.isEnabledFor(HELLO_LOG_LEVEL)) { \
        log4cplus::tostringstream _log4cplus_buf; \
        _log4cplus_buf << logEvent; \
 logger.forcedLog(HELLO_LOG_LEVEL, _log4cplus_buf.str(), __FILE__, __LINE__); \
    }

不过log4cplus没有提供给用户一个接口来实现LEVEL值与字符串的转换，所以当带格式输出LogLevel字符
串时候会显示"UNKNOWN"， 不够理想。比如用TTCCLayout控制输出的结果可能会如下所示：

10-17-04 11:17:51,124 [1075298944] UNKNOWN root <> - info

而不是期望的以下结果：
10-17-04 11:17:51,124 [1075298944] HELLO root <> - info

要想实现第二种结果，按照log4cplus现有的接口机制，只能改其源代码后重新编译，方法是在loglevel.cxx
中加入：

#define _HELLO_STRING LOG4CPLUS_TEXT("HELLO")

然后修改log4cplus::tstring  defaultLogLevelToStringMethod(LogLevel ll)函数，增加一个判断：

case HELLO_LOG_LEVEL:    return _HELLO_STRING;

重新编译log4cplus源代码后生成库文件，再使用时即可实现满意效果。

				
### 调试模式 ###

即通过loglog来控制输出调试、警告或错误信息，见例4，这里不再赘述。

### 基于脚本配置来过滤log信息 ###

除了通过程序实现对log环境的配置之外，log4cplus通过PropertyConfigurator类实现了基于脚本配置的功能。
通过脚本可以完成对logger、appender和layout的配置，因此可以解决怎样输出，输出到哪里的问题，我将在
全文的最后一部分中提到多线程环境中如何利用脚本配置来配合实现性能测试，本节将重点介绍基脚本实现过
滤log信息的功能。

首先简单介绍一下脚本的语法规则：

包括Appender的配置语法和logger的配置语法，其中：

1.Appender的配置语法:

（1）设置名称：

/*设置方法*/
log4cplus.appender.appenderName=fully.qualified.name.of.appender.class

例如（列举了所有可能的Appender，其中SocketAppender后面会讲到）：
log4cplus.appender.append_1=log4cplus::ConsoleAppender
log4cplus.appender.append_2=log4cplus::FileAppender
log4cplus.appender.append_3=log4cplus::RollingFileAppender
log4cplus.appender.append_4=log4cplus::DailyRollingFileAppender
log4cplus.appender.append_4=log4cplus::SocketAppender

（2）设置Filter：

包括选择过滤器和设置过滤条件，可选择的过滤器包括：LogLevelMatchFilter、LogLevelRangeFilter、
和StringMatchFilter：

对LogLevelMatchFilter来说，过滤条件包括LogLevelToMatch和AcceptOnMatch（true|false）， 只有
当log信息的LogLevel值与LogLevelToMatch相同，且AcceptOnMatch为true时才会匹配。

LogLevelRangeFilter来说，过滤条件包括LogLevelMin、LogLevelMax和AcceptOnMatch，只有当log信息
的LogLevel在LogLevelMin、LogLevelMax之间同时AcceptOnMatch为true时才会匹配。

对StringMatchFilter来说，过滤条件包括StringToMatch和AcceptOnMatch，只有当log信息的LogLevel值
与StringToMatch对应的LogLevel值与相同， 且AcceptOnMatch为true时会匹配。

				
过滤条件处理机制类似于IPTABLE的Responsibility chain，（即先deny、再allow）不过执行顺序刚好相反，
后写的条件会被先执行，比如：

log4cplus.appender.append_1.filters.1=log4cplus::spi::LogLevelMatchFilter
log4cplus.appender.append_1.filters.1.LogLevelToMatch=TRACE
log4cplus.appender.append_1.filters.1.AcceptOnMatch=true
#log4cplus.appender.append_1.filters.2=log4cplus::spi::DenyAllFilter

会首先执行filters.2的过滤条件，关闭所有过滤器，然后执行filters.1，仅匹配TRACE信息。

（3）设置Layout

可以选择不设置、TTCCLayout、或PatternLayout

如果不设置，会输出简单格式的log信息。

设置TTCCLayout如下所示：
log4cplus.appender.ALL_MSGS.layout=log4cplus::TTCCLayout

设置PatternLayout如下所示：
log4cplus.appender.append_1.layout=log4cplus::PatternLayout
log4cplus.appender.append_1.layout.ConversionPattern=%d{%m/%d/%y %H:%M:%S,%Q} [%t] %-5p - %m%n

				
2.logger的配置语法

包括rootLogger和non-root logger。

对于rootLogger来说：
log4cplus.rootLogger=[LogLevel], appenderName, appenderName, ...

对于non-root logger来说：
log4cplus.logger.logger_name=[LogLevel|INHERITED], appenderName, appenderName, ...

				
脚本方式使用起来非常简单，只要首先加载配置即可（urconfig.properties是自行定义的配置文件）：

PropertyConfigurator::doConfigure("urconfig.properties");

				
下面我们通过例子体会一下log4cplus强大的基于脚本过滤log信息的功能。

				
〖例8〗

/*
 *    urconfig.properties
 */
log4cplus.rootLogger=TRACE, ALL_MSGS, TRACE_MSGS, DEBUG_INFO_MSGS, FATAL_MSGS

log4cplus.appender.ALL_MSGS=log4cplus::RollingFileAppender
log4cplus.appender.ALL_MSGS.File=all_msgs.log
log4cplus.appender.ALL_MSGS.layout=log4cplus::TTCCLayout

log4cplus.appender.TRACE_MSGS=log4cplus::RollingFileAppender
log4cplus.appender.TRACE_MSGS.File=trace_msgs.log
log4cplus.appender.TRACE_MSGS.layout=log4cplus::TTCCLayout
log4cplus.appender.TRACE_MSGS.filters.1=log4cplus::spi::LogLevelMatchFilter
log4cplus.appender.TRACE_MSGS.filters.1.LogLevelToMatch=TRACE
log4cplus.appender.TRACE_MSGS.filters.1.AcceptOnMatch=true
log4cplus.appender.TRACE_MSGS.filters.2=log4cplus::spi::DenyAllFilter

log4cplus.appender.DEBUG_INFO_MSGS=log4cplus::RollingFileAppender
log4cplus.appender.DEBUG_INFO_MSGS.File=debug_info_msgs.log
log4cplus.appender.DEBUG_INFO_MSGS.layout=log4cplus::TTCCLayout
log4cplus.appender.DEBUG_INFO_MSGS.filters.1=log4cplus::spi::LogLevelRangeFilter
log4cplus.appender.DEBUG_INFO_MSGS.filters.1.LogLevelMin=DEBUG
log4cplus.appender.DEBUG_INFO_MSGS.filters.1.LogLevelMax=INFO
log4cplus.appender.DEBUG_INFO_MSGS.filters.1.AcceptOnMatch=true
log4cplus.appender.DEBUG_INFO_MSGS.filters.2=log4cplus::spi::DenyAllFilter

log4cplus.appender.FATAL_MSGS=log4cplus::RollingFileAppender
log4cplus.appender.FATAL_MSGS.File=fatal_msgs.log
log4cplus.appender.FATAL_MSGS.layout=log4cplus::TTCCLayout
log4cplus.appender.FATAL_MSGS.filters.1=log4cplus::spi::StringMatchFilter
log4cplus.appender.FATAL_MSGS.filters.1.StringToMatch=FATAL
log4cplus.appender.FATAL_MSGS.filters.1.AcceptOnMatch=true
log4cplus.appender.FATAL_MSGS.filters.2=log4cplus::spi::DenyAllFilter

				
/*
 *    main.cpp
 */
#include <log4cplus/logger.h>
#include <log4cplus/configurator.h>
#include <log4cplus/helpers/stringhelper.h>

using namespace log4cplus;

static Logger logger = Logger::getInstance("log");

void printDebug()
{
    LOG4CPLUS_TRACE_METHOD(logger, "::printDebug()");
    LOG4CPLUS_DEBUG(logger, "This is a DEBUG message");
    LOG4CPLUS_INFO(logger, "This is a INFO message");
    LOG4CPLUS_WARN(logger, "This is a WARN message");
    LOG4CPLUS_ERROR(logger, "This is a ERROR message");
    LOG4CPLUS_FATAL(logger, "This is a FATAL message");
}
int main()
{
    Logger root = Logger::getRoot();
    PropertyConfigurator::doConfigure("urconfig.properties");
    printDebug();

    return 0;
}

运行结果：

1. all_msgs.log
10-17-04 14:55:25,858 [1075298944] TRACE log <> - ENTER: ::printDebug()
10-17-04 14:55:25,871 [1075298944] DEBUG log <> - This is a DEBUG message
10-17-04 14:55:25,873 [1075298944] INFO log <> - This is a INFO message
10-17-04 14:55:25,873 [1075298944] WARN log <> - This is a WARN message
10-17-04 14:55:25,874 [1075298944] ERROR log <> - This is a ERROR message
10-17-04 14:55:25,874 [1075298944] FATAL log <> - This is a FATAL message
10-17-04 14:55:25,875 [1075298944] TRACE log <> - EXIT:  ::printDebug()

2. trace_msgs.log
10-17-04 14:55:25,858 [1075298944] TRACE log <> - ENTER: ::printDebug()
10-17-04 14:55:25,875 [1075298944] TRACE log <> - EXIT:  ::printDebug()

3. debug_info_msgs.log
10-17-04 14:55:25,871 [1075298944] DEBUG log <> - This is a DEBUG message
10-17-04 14:55:25,873 [1075298944] INFO log <> - This is a INFO message

4. fatal_msgs.log
10-17-04 14:55:25,874 [1075298944] FATAL log <> - This is a FATAL message

本部分详细介绍了如何有选择地控制log信息的输出，最后一部分我们将介绍一下多线程、
和C/S模式下该如何操作，顺便提一下NDC的概念。

### 一些可以改进之处 ###

1. 用户自定义LogLevel的实现机制不够开放

在第五篇中曾经介绍过如何实现用户自行定义LogLevel，为了实现比较理想的效果，甚至还需要改log4cplus
的源代码。：（

2. 生成Logger对象的机制可以改进

我在使用时候，经常需要在不同的文件、函数中操作同一个logger，虽然log4cplus实现了树状存储以及根据
名称生成Logger，却没有充分利用这样的特点确保同一个名称对应的logger对象的唯一性，比如以下代码：

    ... ...
    
    Logger logger1 = Logger::getInstance("test");
    Logger logger2 = Logger::getInstance("test");

    Logger * plogger1 = &logger1;
    Logger * plogger2 = &logger2;

    std::cout << "plogger1: " << plogger1 << std::endl << "plogger2: " << plogger2 << std::endl;
    
    ... ...
    
    
运行结果：

plogger1: 0xbfffe5a0
plogger2: 0xbfffe580

				
从结果可以看出，明明是同一个Logger，但每次调用都会产生一个Logger副本，虽然结果是正确的（因为将存
储和操作分开了），但是资源有些浪费，我看了一下log4cplus的代码，其实可以按照如下方式实现（示意性
的）：

#include <iostream>
#include <string>
#include <map>

/* forward declaration */
class Logger;

class LoggerContainer
{
public:

    ~LoggerContainer();

    Logger * getinstance(const std::string & strLogger);

private:

    typedef std::map<:string,> LoggerMap;
    LoggerMap loggerPtrs;
};

class Logger
{
public:
     Logger() {std::cout << "ctor of Logger " << std::endl; }
    ~Logger() {std::cout << "dtor of Logger " << std::endl; }

    static Logger * getInstance( const std::string & strLogger)
    {
        static LoggerContainer defaultLoggerContainer;
        return defaultLoggerContainer.getinstance(strLogger);
    }
};

LoggerContainer::~LoggerContainer()
{
    /* release all ptr in LoggerMap */
    LoggerMap::iterator itr = loggerPtrs.begin();

    for( ; itr != loggerPtrs.end(); ++itr )
 {
     delete (*itr).second;
 }

}

Logger * LoggerContainer::getinstance(const std::string & strLogger)
{
   LoggerMap::iterator itr = loggerPtrs.find(strLogger);

   if(itr != loggerPtrs.end())
   {
       /* logger exist, just return it */
       return (*itr).second;
   }
   else
   {
       /* return a new logger */
       Logger * plogger = new Logger();
       loggerPtrs.insert(std::make_pair(strLogger, plogger));

       return plogger;
   }
}

int main()
{
    Logger * plogger1 = Logger::getInstance("test");
    Logger * plogger2 = Logger::getInstance("test");

    std::cout << "plogger1: " << plogger1 << std::endl << "plogger2: " << plogger2 << std::endl;

    return 0;
}

				
运行结果：

ctor of Logger
plogger1: 0x804fc30
plogger2: 0x804fc30
dtor of Logger

这里的LoggerContainer相当于log4cplus中的Hierarchy类，结果可以看出，通过同一个名称可以获取相同的
Logger实例。

				
还有一些小毛病比如RollingFileAppender和DailyRollingFileAppender的参数输入顺序可以调整成统一方式
等等，就不细说了。

本部分提到了使用log4cplus时候感觉不爽的地方，最后一部分将介绍一下log4cplus中线程和套接字实现情况

				
### 基本使用 ###

使用log4cplus有六个基本步骤：

1. 实例化一个appender对象
2. 实例化一个layout对象
3. 将layout对象绑定(attach)到appender对象
4. 实例化一个logger对象,调用静态函数：log4cplus::Logger::getInstance("logger_name")
5. 将appender对象绑定(attach)到logger对象，如省略此步骤，标准输出（屏幕）appender对象会绑定到logger
6. 设置logger的优先级，如省略此步骤，各种有限级的消息都将被记录

下面通过一些例子来了解log4cplus的基本使用。

〖例1〗
/*
    严格实现步骤1-6，appender输出到屏幕, 其中的布局格式和LogLevel后面会详细解释。
*/
#include <log4cplus/logger.h>
#include <log4cplus/consoleappender.h>
#include <log4cplus/layout.h>

using namespace log4cplus;
using namespace log4cplus::helpers;

int main()
{
    /* step 1: Instantiate an appender object */
    SharedObjectPtr _append (new ConsoleAppender());
    _append->setName("append for test");

    /* step 2: Instantiate a layout object */
    std::string pattern = "%d{%m/%d/%y %H:%M:%S}  - %m [%l]%n";
    std::auto_ptr _layout(new PatternLayout(pattern));

    /* step 3: Attach the layout object to the appender */
    _append->setLayout( _layout );

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

    /* step 6: Set a priority for the logger  */
    _logger.setLogLevel(ALL_LOG_LEVEL);

     /* log activity */
    LOG4CPLUS_DEBUG(_logger, "This is the FIRST log message...")
    sleep(1);
    LOG4CPLUS_WARN(_logger, "This is the SECOND log message...")

    return 0;
}

输出结果：
10/14/04 09:06:24  - This is the FIRST log message... [main.cpp:31]
10/14/04 09:06:25  - This is the SECOND log message... [main.cpp:33]

				
〖例2〗
/*
    简洁使用模式，appender输出到屏幕。
*/
#include <log4cplus/logger.h>
#include <log4cplus/consoleappender.h>

using namespace log4cplus;
using namespace log4cplus::helpers;

int main()
{
    /* step 1: Instantiate an appender object */
    SharedAppenderPtr _append(new ConsoleAppender());
    _append->setName("append test");

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

    /* log activity */
    LOG4CPLUS_DEBUG(_logger, "This is the FIRST log message...")
    sleep(1);
    LOG4CPLUS_WARN(_logger, "This is the SECOND log message...")

    return 0;
}

输出结果：
DEBUG - This is the FIRST log message...
WARN - This is the SECOND log message...

				
〖例3〗
/*
    iostream模式，appender输出到屏幕。
*/
#include <log4cplus/logger.h>
#include <log4cplus/consoleappender.h>
#include <iomanip> /* 其实这个东东还是放到log4cplus头文件中比较合适些，个人意见：） */using namespace log4cplus;

int main()
{
    /* step 1: Instantiate an appender object */
    SharedAppenderPtr _append(new ConsoleAppender());
    _append->setName("append test");

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

    /* log activity */
    LOG4CPLUS_TRACE(_logger, "This is"  << " just a t" << "est." << std::endl)
    LOG4CPLUS_DEBUG(_logger, "This is a bool: " << true)
    LOG4CPLUS_INFO(_logger, "This is a char: " << 'x')
    LOG4CPLUS_WARN(_logger, "This is a int: " << 1000)
    LOG4CPLUS_ERROR(_logger, "This is a long(hex): " << std::hex << 100000000)
    LOG4CPLUS_FATAL(_logger, "This is a double: "  << std::setprecision(15)  << 1.2345234234)

    return 0;
}

输出结果：
DEBUG - This is a bool: 1
INFO - This is a char: x
WARN - This is a int: 1000
ERROR - This is a long(hex): 5f5e100
FATAL - This is a double: 1.2345234234

				
〖例4〗
/*
    调试模式，通过loglog来控制输出调试、警告或错误信息，appender输出到屏幕。
*/
#include <iostream>
#include <log4cplus/helpers/loglog.h>

using namespace log4cplus::helpers;

void printMsgs(void)
{
    std::cout << "Entering printMsgs()..." << std::endl;
    LogLog::getLogLog()->debug("This is a Debug statement...");
    LogLog::getLogLog()->warn("This is a Warning...");
    LogLog::getLogLog()->error("This is a Error...");
    std::cout << "Exiting printMsgs()..." << std::endl << std::endl;
}

int main()
{
    /*
       LogLog类实现了debug, warn, error 函数用于输出调试、警告或错误信息，
       同时提供了两个方法来进一步控制所输出的信息，其中：

       setInternalDebugging方法用来控制是否屏蔽输出信息中的调试信息，当输入
       参数为false则屏蔽，缺省设置为false。

       setQuietMode方法用来控制是否屏蔽所有输出信息，当输入参数为true则屏蔽，
       缺省设置为false。

       LogLog::getLogLog()->setInternalDebugging(false);
    */

    printMsgs();

    std::cout << "Turning on debug..." << std::endl;
    LogLog::getLogLog()->setInternalDebugging(true);
    printMsgs();

    std::cout << "Turning on quiet mode..." << std::endl;
    LogLog::getLogLog()->setQuietMode(true);
    printMsgs();

    return 0;
}

输出结果：
Entering printMsgs()...
log4cplus:WARN This is a Warning...
log4cplus:ERROR This is a Error...
Exiting printMsgs()...

Turning on debug...
Entering printMsgs()...
log4cplus: This is a Debug statement...
log4cplus:WARN This is a Warning...
log4cplus:ERROR This is a Error...
Exiting printMsgs()...

Turning on quiet mode...
Entering printMsgs()...
Exiting printMsgs()...

需要指出的是，输出信息中总是包含"log4cplus:"前缀，有时候会感觉不爽，这是因为LogLog在实现时候死定了要这么写：

LogLog::LogLog()
 : mutex(LOG4CPLUS_MUTEX_CREATE),
   debugEnabled(false),
   quietMode(false),
   PREFIX( LOG4CPLUS_TEXT("log4cplus: ") ),
   WARN_PREFIX( LOG4CPLUS_TEXT("log4cplus:WARN ") ),
   ERR_PREFIX( LOG4CPLUS_TEXT("log4cplus:ERROR ") )
{
}

你可以把这些前缀换成自己看着爽的提示符号，然后重新编译，hihi。除非万不得已或者实在郁闷的不行，否则还是不要这样干。

				
〖例5〗
/*    文件模式，appender输出到文件。*/
#include <log4cplus/logger.h>
#include <log4cplus/fileappender.h>
using namespace log4cplus;
int main()
{    
/* step 1: Instantiate an appender object */
    SharedAppenderPtr _append(new FileAppender("Test.log"));
    _append->setName("file log test");
    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test.subtestof_filelog");
    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);
    /* log activity */
    int i;
    for( i = 0; i < 5; ++i )
    {
        LOG4CPLUS_DEBUG(_logger, "Entering loop #" << i << "End line #")
    }
    return 0;
}

输出结果（Test.log文件）：

DEBUG - Entering loop #0End line #
DEBUG - Entering loop #1End line #
DEBUG - Entering loop #2End line #
DEBUG - Entering loop #3End line #
DEBUG - Entering loop #4End line #

				
### 如何控制输出消息的格式 ###

前面已经讲过，log4cplus通过布局器（Layouts）来控制输出的格式，log4cplus提供了三种类型的Layouts，
分别是SimpleLayout、PatternLayout、和TTCCLayout。其中：

1. SimpleLayout
是一种简单格式的布局器，在输出的原始信息之前加上LogLevel和一个"-"。

比如以下代码片段：

    ... ...

    /* step 1: Instantiate an appender object */
    SharedObjectPtr _append (new ConsoleAppender());
    _append->setName("append for test");

    /* step 2: Instantiate a layout object */
    std::auto_ptr  _layout(new log4cplus::SimpleLayout());

    /* step 3: Attach the layout object to the appender */
    _append->setLayout( _layout );

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

     /* log activity */
    LOG4CPLUS_DEBUG(_logger, "This is the simple formatted log message...")
    
    ... ...
    
    
将打印结果：
DEBUG - This is the simple formatted log message...

2. PatternLayout
是一种有词法分析功能的模式布局器，一提起模式就会想起正则表达式，这里的模式和正则表达式类似，但是
远比后者简单，能够对预定义的标识符（称为conversion specifiers）进行解析，转换成特定格式输出。以下
代码片段演示了如何使用PatternLayout：

    ... ...

    /* step 1: Instantiate an appender object */
    SharedObjectPtr _append (new ConsoleAppender());
    _append->setName("append for test");
   
    /* step 2: Instantiate a layout object */
    std::string pattern = "%d{%m/%d/%y %H:%M:%S}  - %m [%l]%n";
    std::auto_ptr _layout(new PatternLayout(pattern));
    
    /* step 3: Attach the layout object to the appender */
    _append->setLayout( _layout );

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test_logger.subtest");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

     /* log activity */
    LOG4CPLUS_DEBUG(_logger, "teststr")
    
    ... ...
    
输出结果：
10/16/04 18:51:25  - teststr [main.cpp:51]

可以看出通过填写特定格式的模式字符串"pattern"，原始信息被包含到一堆有格式的信息当中了，这就使得
用户可以根据自身需要来定制显示内容。"pattern"可以包含普通字符串和预定义的标识符，其中：

（1）普通字符串，能够被直接显示的信息。
（2）预定义标识符，通过"%"与一个或多个字符共同构成预定义的标识符，能够产生出特定格式信息。

关于预定义标识符，log4cplus文档中提供了详细的格式说明，我每种都试了一下，以上述代码为例，根据不同
的pattern，各种消息格式使用情况列举如下：

（1）"%%"，转义为%, 即，std::string pattern = "%%" 时输出: "%"
（2）"%c"，输出logger名称，比如std::string pattern ="%c" 时输出: "test_logger.subtest"，
     也可以控制logger名称的显示层次，比如"%c{1}"时输出"test_logger"，其中数字表示层次。
（3）"%D"，显示本地时间，当std::string pattern ="%D" 时输出:"2004-10-16 18:55:45"，%d显示标准时间，
     所以当std::string pattern ="%d" 时输出 "2004-10-16 10:55:45" （因为我们是东8区，差8个小时啊）。
     可以通过%d{...}定义更详细的显示格式，比如%d{%H:%M:%s}表示要显示小时:分钟：秒。大括号中可显示的
     预定义标识符如下：
     
%a -- 表示礼拜几，英文缩写形式，比如"Fri"
%A -- 表示礼拜几，比如"Friday"
%b -- 表示几月份，英文缩写形式，比如"Oct"
%B -- 表示几月份，"October"
%c -- 标准的日期＋时间格式，如 "Sat Oct 16 18:56:19 2004"
%d -- 表示今天是这个月的几号(1-31)"16"
%H -- 表示当前时刻是几时(0-23)，如 "18"
%I -- 表示当前时刻是几时(1-12)，如 "6"
%j -- 表示今天是哪一天(1-366)，如 "290"
%m -- 表示本月是哪一月(1-12)，如 "10"
%M -- 表示当前时刻是哪一分钟(0-59)，如 "59"
%p -- 表示现在是上午还是下午， AM or PM
%q -- 表示当前时刻中毫秒部分(0-999)，如 "237"
%Q -- 表示当前时刻中带小数的毫秒部分(0-999.999)，如 "430.732"
%S -- 表示当前时刻的多少秒(0-59)，如 "32"
%U -- 表示本周是今年的第几个礼拜，以周日为第一天开始计算(0-53)，如 "41"
%w -- 表示礼拜几，(0-6, 礼拜天为0)，如 "6"
%W -- 表示本周是今年的第几个礼拜，以周一为第一天开始计算(0-53)，如 "41"
%x -- 标准的日期格式，如 "10/16/04"
%X -- 标准的时间格式，如 "19:02:34"
%y -- 两位数的年份(0-99)，如 "04"
%Y -- 四位数的年份，如 "2004"
%Z -- 时区名，比如 "GMT"

（4）"%F"，输出当前记录器所在的文件名称，比如std::string pattern ="%F" 时输出: "main.cpp"
（5）"%L"，输出当前记录器所在的文件行号，比如std::string pattern ="%L" 时输出: "51"
（6）"%l"，输出当前记录器所在的文件名称和行号，比如std::string pattern ="%L" 时输出:
     "main.cpp:51"
（7）"%m"，输出原始信息，比如std::string pattern ="%m" 时输出: "teststr"，即上述代码中
     LOG4CPLUS_DEBUG的第二个参数，这种实现机制可以确保原始信息被嵌入到带格式的信息中。
（8）"%n"，换行符，没什么好解释的
（9）"%p"，输出LogLevel，比如std::string pattern ="%p" 时输出: "DEBUG"
（10）"%t"，输出记录器所在的线程ID，比如std::string pattern ="%t" 时输出: "1075298944"
（11）"%x"，嵌套诊断上下文NDC (nested diagnostic context) 输出，从堆栈中弹出上下文信息，NDC可以用对
      不同源的log信息（同时地）交叉输出进行区分，关于NDC方面的详细介绍会在下文中提到。
（12）格式对齐，比如std::string pattern ="%-10m"时表示左对齐，宽度是10，此时会输出"teststr   "，当
      然其它的控制字符也可以相同的方式来使用，比如"%-12d"，"%-5p"等等（刚接触log4cplus文档时还以为
      "%-5p"整个字符串代表LogLevel呢，呵呵）。

      
3. TTCCLayout
是在PatternLayout基础上发展的一种缺省的带格式输出的布局器， 其格式由时间，线程ID，Logger和NDC 组
成（consists of time, thread, Logger and nested diagnostic context information, hence the name），
因而得名（怎么得名的？Logger里哪里有那个"C"的缩写啊！名字起得真够烂的，想扁人）。提供给那些想显示
典型的信息（一般情况下够用了）又懒得配置pattern的同志们。

TTCCLayout在构造时有机会选择显示本地时间或GMT时间，缺省是按照本地时间显示：
TTCCLayout::TTCCLayout(bool use_gmtime  = false)

以下代码片段演示了如何使用TTCCLayout：

    ... ...

    /* step 1: Instantiate an appender object */
    SharedObjectPtr _append (new ConsoleAppender());
    _append->setName("append for test");

    /* step 2: Instantiate a layout object */
    std::auto_ptr _layout(new TTCCLayout());

    /* step 3: Attach the layout object to the appender */
    _append->setLayout( _layout );

    /* step 4: Instantiate a logger object */
    Logger _logger = Logger::getInstance("test_logger");

    /* step 5: Attach the appender object to the logger  */
    _logger.addAppender(_append);

     /* log activity */
    LOG4CPLUS_DEBUG(_logger, "teststr")
    
    ... ...
    
输出结果：
10-16-04 19:08:27,501 [1075298944] DEBUG test_logger <> - teststr

				
当构造TTCCLayout对象时选择GMT时间格式时：

    ... ...
    
    /* step 2: Instantiate a layout object */
    std::auto_ptr _layout(new TTCCLayout(true));
    
    ... ...
    
输出结果：
10-16-04 11:12:47,678 [1075298944] DEBUG test_logger <> - teststr

				
本文介绍了控制log信息格式的相关知识，下一部分将详细介绍log信息的几种文件操作方式。

				
### 简介 ###

log4cplus是C++编写的开源的日志系统，前身是java编写的log4j系统.受Apache Software License
保护。作者是Tad E. Smith。log4cplus具有线程安全、灵活、以及多粒度控制的特点，通过将信息划分
优先级使其可以面向程序调试、运行、测试、和维护等全生命周期； 你可以选择将信息输出到屏幕、文件、
NT event log、甚至是远程服务器；通过指定策略对日志进行定期备份等等。

### 下载 ###

最新的log4cplus可以从以下网址下载 http://log4cplus.sourceforge.net
本文使用的版本为：1.0.2

### 安装 ###

1. linux下安装

tar xvzf log4cplus-x.x.x.tar.gz
cd log4cplus-x.x.x
./configure --prefix=/where/to/install
make
make install

这里我采用缺省安装路径：/usr/local，下文如无特别说明，均以此路径为准。

2. windows下安装

不需要安装，有一个msvc6存放包括源代码和用例在内的开发工程（for VC6 only），使用之前请先编译
"log4cplus_dll class"工程生成dll，或者编译"log4cplus_static class"工程生成lib.

### 使用前的配置 ###

1. linux下的配置

确保你的Makefile中包含 /usr/local/lib/liblog4cplus.a（静态库）或  -llog4cplus（动态库）即可，
头文件在/usr/local/include/log4cplus目录下。对于动态库，要想正常使用，还得将库安装路径加入到
LD_LIBRARY_PATH 中，我一般是这样做的：以管理员身份登录，在/etc/ld.so.conf中加入安装路径，这里
是/usr/local/lib，然后执行ldconfig使设置生效即可。

2. windows下的配置

将"log4cplus_dll class"工程或"log4cplus_static class"工程的dsp 文件插入到你的工程中，或者直接
把两个工程编译生成的库以及头文件所在目录放到你的工程的搜索路径中，如果你使用静态库，请在你的工程中
"project/setting/C++"的preprocessor definitions中加入LOG4CPLUS_STATIC。

### 构成要素介绍 ###

虽然功能强大，应该说log4cplus用起来还是比较复杂的，为了更好地使用它，先介绍一下它的基本要素。

Layouts      ：布局器，控制输出消息的格式.
Appenders    ：挂接器，与布局器紧密配合，将特定格式的消息输出到所挂接的设备终端
               （如屏幕，文件等等)。
Logger       ：记录器，保存并跟踪对象日志信息变更的实体，当你需要对一个对象进行
               记录时，就需要生成一个logger。
Categories   ：分类器，层次化（hierarchy）的结构，用于对被记录信息的分类，层次中
               每一个节点维护一个logger的所有信息。
Priorities   ：优先权，包括TRACE, DEBUG, INFO, WARNING, ERROR, FATAL。

				
本文介绍了log4cplus基本概念，以及如何安装，配置，下一篇将通过例子介绍如何使用log4cplus。

												
														

														void* operator new( size_t nSize, char* pszFileName, int nLineNum )
void* operator new[]( size_t nSize, char* pszFileName, int nLineNum )
void operator delete( void *ptr )
void operator delete[]( void *ptr )

												
										

我们为 operator new 定义了一个新的版本，除了必须的 size_t nSize 参数外，还增加了文件名和行号，这里的文件名和行号就是这次 new operator 操作符被调用时所在的文件名和行号，这个信息将在发现内存泄漏时输出，以帮助用户定位泄漏具体位置。对于 operator delete，因为无法为之定义新的版本，我们直接覆盖了全局的 operator delete 的两个版本。

在重载的 operator new 函数版本中，我们将调用全局的 operator new 的相应的版本并将相应的 size_t 参数传入，而后，我们将全局 operator new 返回的指针值以及该次分配所在的文件名和行号信息记录下来，这里所采用的数据结构是一个 STL 的 map，以指针值为 key 值。当 operator delete 被调用时，如果调用方式正确的话（调用方式不正确的情况将在后面详细描述），我们就能以传入的指针值在 map 中找到相应的数据项并将之删除，而后调用 free 将指针所指向的内存块释放。当程序退出的时候，map 中的剩余的数据项就是我们企图检测的内存泄漏信息－－已经在堆上分配但是尚未释放的分配信息。

以上就是内存检测实现的基本原理，现在还有两个基本问题没有解决：

1) 如何取得内存分配代码所在的文件名和行号，并让 new operator 将之传递给我们重载的 operator new。

2) 我们何时创建用于存储内存数据的 map 数据结构，如何管理，何时打印内存泄漏信息。

先解决问题1。首先我们可以利用 C 的预编译宏 __FILE__ 和 __LINE__，这两个宏将在编译时在指定位置展开为该文件的文件名和该行的行号。而后我们需要将缺省的全局 new operator 替换为我们自定义的能够传入文件名和行号的版本，我们在子系统头文件 MemRecord.h 中定义：

												
														
																
#define DEBUG_NEW new(__FILE__, __LINE__ )

												
										

而后在所有需要使用内存检测的客户程序的所有的 cpp 文件的开头加入

												
														
																
#include "MemRecord.h"
#define new DEBUG_NEW

												
										

就可以将客户源文件中的对于全局缺省的 new operator 的调用替换为 new (__FILE__,__LINE__) 调用，而该形式的new operator将调用我们的operator new (size_t nSize, char* pszFileName, int nLineNum)，其中 nSize 是由 new operator 计算并传入的，而 new 调用点的文件名和行号是由我们自定义版本的 new operator 传入的。我们建议在所有用户自己的源代码文件中都加入上述宏，如果有的文件中使用内存检测子系统而有的没有，则子系统将可能因无法监控整个系统而输出一些泄漏警告。

再说第二个问题。我们用于管理客户信息的这个 map 必须在客户程序第一次调用 new operator 或者 delete operator 之前被创建，而且在最后一个 new operator 和 delete operator 调用之后进行泄漏信息的打印，也就是说它需要先于客户程序而出生，而在客户程序退出之后进行分析。能够包容客户程序生命周期的确有一人--全局对象（appMemory）。我们可以设计一个类来封装这个 map 以及这对它的插入删除操作，然后构造这个类的一个全局对象（appMemory），在全局对象（appMemory）的构造函数中创建并初始化这个数据结构，而在其析构函数中对数据结构中剩余数据进行分析和输出。Operator new 中将调用这个全局对象（appMemory）的 insert 接口将指针、文件名、行号、内存块大小等信息以指针值为 key 记录到 map 中，在 operator delete 中调用 erase 接口将对应指针值的 map 中的数据项删除，注意不要忘了对 map 的访问需要进行互斥同步，因为同一时间可能会有多个线程进行堆上的内存操作。

好啦，内存检测的基本功能已经具备了。但是不要忘了，我们为了检测内存泄漏，在全局的 operator new 增加了一层间接性，同时为了保证对数据结构的安全访问增加了互斥，这些都会降低程序运行的效率。因此我们需要让用户能够方便的 enable 和 disable 这个内存检测功能，毕竟内存泄漏的检测应该在程序的调试和测试阶段完成。我们可以使用条件编译的特性，在用户被检测文件中使用如下宏定义：

												
														
																
#include "MemRecord.h"
#if defined( MEM_DEBUG )
#define new DEBUG_NEW
#endif

												
										

当用户需要使用内存检测时，可以使用如下命令对被检测文件进行编译

												
														
																

																g++ -c -DMEM_DEBUG xxxxxx.cpp
																

														
												
										

就可以 enable 内存检测功能，而用户程序正式发布时，可以去掉 -DMEM_DEBUG 编译开关来 disable 内存检测功能，消除内存检测带来的效率影响。

图2所示为使用内存检测功能后，内存泄漏代码的执行以及检测结果

图2

4．错误方式删除带来的问题
以上我们已经构建了一个具备基本内存泄漏检测功能的子系统，下面让我们来看一下关于内存泄漏方面的一些稍微高级一点的话题。

首先，在我们编制 c++ 应用时，有时需要在堆上创建单个对象，有时则需要创建对象的数组。关于 new 和 delete 原理的叙述我们可以知道，对于单个对象和对象数组来说，内存分配和删除的动作是大不相同的，我们应该总是正确的使用彼此搭配的 new 和 delete 形式。但是在某些情况下，我们很容易犯错误，比如如下代码：

												
														
																
		class Test {};
		……
		Test* pAry = new Test[10];//创建了一个拥有 10 个 Test 对象的数组
		Test* pObj = new Test;//创建了一个单对象
		……
		delete []pObj;//本应使用单对象形式 delete pObj 进行内存释放，却错误的使用了数
//组形式
		delete pAry;//本应使用数组形式 delete []pAry 进行内存释放，却错误的使用了单对
//象的形式

												
										

不匹配的 new 和 delete 会导致什么问题呢？C++ 标准对此的解答是"未定义"，就是说没有人向你保证会发生什么，但是有一点可以肯定：大多不是好事情--在某些编译器形成的代码中，程序可能会崩溃，而另外一些编译器形成的代码中，程序运行可能毫无问题，但是可能导致内存泄漏。

既然知道形式不匹配的 new 和 delete 会带来的问题，我们就需要对这种现象进行毫不留情的揭露，毕竟我们重载了所有形式的内存操作 operator new，operator new[]，operator delete，operator delete[]。

我们首先想到的是，当用户调用特定方式（单对象或者数组方式）的 operator new 来分配内存时，我们可以在指向该内存的指针相关的数据结构中，增加一项用于描述其分配方式。当用户调用不同形式的 operator delete 的时候，我们在 map 中找到与该指针相对应的数据结构，然后比较分配方式和释放方式是否匹配，匹配则在 map 中正常删除该数据结构，不匹配则将该数据结构转移到一个所谓 "ErrorDelete" 的 list 中，在程序最终退出的时候和内存泄漏信息一起打印。

上面这种方法是最顺理成章的，但是在实际应用中效果却不好。原因有两个，第一个原因我们上面已经提到了：当 new 和 delete 形式不匹配时，其结果"未定义"。如果我们运气实在太差--程序在执行不匹配的 delete 时崩溃了，我们的全局对象（appMemory）中存储的数据也将不复存在，不会打印出任何信息。第二个原因与编译器相关，前面提到过，当编译器处理自定义数据类型或者自定义数据类型数组的 new 和 delete 操作符的时候，通常使用编译器相关的 cookie 技术。这种 cookie 技术在编译器中可能的实现方式是：new operator 先计算容纳所有对象所需的内存大小，而后再加上它为记录 cookie 所需要的内存量，再将总容量传给operator new 进行内存分配。当 operator new 返回所需的内存块后，new operator 将在调用相应次数的构造函数初始化有效数据的同时，记录 cookie 信息。而后将指向有效数据的指针返回给用户。也就是说我们重载的 operator new 所申请到并记录下来的指针与 new operator 返回给调用者的指针不一定一致（图3）。当调用者将 new operator 返回的指针传给 delete operator 进行内存释放时，如果其调用形式相匹配，则相应形式的 delete operator 会作出相反的处理，即调用相应次数的析构函数，再通过指向有效数据的指针位置找出包含 cookie 的整块内存地址，并将其传给 operator delete 释放内存。如果调用形式不匹配，delete operator 就不会做上述运算，而直接将指向有效数据的指针（而不是真正指向整块内存的指针）传入 operator delete。因为我们在 operator new 中记录的是我们所分配的整块内存的指针，而现在传入 operator delete 的却不是，所以就无法在全局对象（appMemory）所记录的数据中找到相应的内存分配信息。

图3

综上所述，当 new 和 delete 的调用形式不匹配时，由于程序有可能崩溃或者内存子系统找不到相应的内存分配信息，在程序最终打印出 "ErrorDelete" 的方式只能检测到某些"幸运"的不匹配现象。但我们总得做点儿什么，不能让这种危害极大的错误从我们眼前溜走，既然不能秋后算帐，我们就实时输出一个 warning 信息来提醒用户。什么时候抛出一个 warning 呢？很简单，当我们发现在 operator delete 或 operator delete[] 被调用的时候，我们无法在全局对象（appMemory）的 map 中找到与传入的指针值相对应的内存分配信息，我们就认为应该提醒用户。

既然决定要输出warning信息，那么现在的问题就是：我们如何描述我们的warning信息才能更便于用户定位到不匹配删除错误呢？答案：在 warning 信息中打印本次 delete 调用的文件名和行号信息。这可有点困难了，因为对于 operator delete 我们不能向对象 operator new 一样做出一个带附加信息的重载版本，我们只能在保持其接口原貌的情况下，重新定义其实现，所以我们的 operator delete 中能够得到的输入只有指针值。在 new/delete 调用形式不匹配的情况下，我们很有可能无法在全局对象（appMemory）的 map 中找到原来的 new 调用的分配信息。怎么办呢？万不得已，只好使用全局变量了。我们在检测子系统的实现文件中定义了两个全局变量（DELETE_FILE, DELETE_LINE）记录 operator delete 被调用时的文件名和行号，同时为了保证并发的 delete 操作对这两个变量访问同步，还使用了一个 mutex（至于为什么是 CCommonMutex 而不是一个 pthread_mutex_t，在"实现上的问题"一节会详细论述，在这里它的作用就是一个 mutex）。

												
														
																
char DELETE_FILE[ FILENAME_LENGTH ] = {0};
int DELETE_LINE = 0;
CCommonMutex globalLock;

												
										

而后，在我们的检测子系统的头文件中定义了如下形式的 DEBUG_DELETE

												
														
																
			extern char DELETE_FILE[ FILENAME_LENGTH ];
extern int DELETE_LINE;
extern CCommonMutex globalLock;//在后面解释
#define DEBUG_DELETE 	globalLock.Lock(); \
			if (DELETE_LINE != 0) BuildStack();\ （//见第六节解释）
			strncpy( DELETE_FILE, __FILE__,FILENAME_LENGTH - 1 );\
			DELETE_FILE[ FILENAME_LENGTH - 1 ]= '\0'; \
			DELETE_LINE = __LINE__; \
			delete

												
										

在用户被检测文件中原来的宏定义中添加一条：

												
														
																
#include "MemRecord.h"
#if defined( MEM_DEBUG )
#define new DEBUG_NEW
#define delete DEBUG_DELETE
#endif

												
										

这样，在用户被检测文件调用 delete operator 之前，将先获得互斥锁，然后使用调用点文件名和行号对相应的全局变量（DELETE_FILE,DELETE_LINE）进行赋值，而后调用 delete operator。当 delete operator 最终调用我们定义的 operator delete 的时候，在获得此次调用的文件名和行号信息后，对文件名和行号全局变量（DELETE_FILE,DELETE_LINE）重新初始化并打开互斥锁，让下一个挂在互斥锁上的 delete operator 得以执行。

在对 delete operator 作出如上修改以后，当我们发现无法经由 delete operator 传入的指针找到对应的内存分配信息的时候，就打印包括该次调用的文件名和行号的 warning。

天下没有十全十美的事情，既然我们提供了一种针对错误方式删除的提醒方法，我们就需要考虑以下几种异常情况：

1．用户使用的第三方库函数中有内存分配和释放操作。或者用户的被检测进程中进行内存分配和释放的实现文件没有使用我们的宏定义。由于我们替换了全局的 operator delete，这种情况下的用户调用的 delete 也会被我们截获。用户并没有使用我们定义的DEBUG_NEW 宏，所以我们无法在我们的全局对象（appMemory）数据结构中找到对应的内存分配信息，但是由于它也没有使用DEBUG_DELETE，我们为 delete 定义的两个全局 DELETE_FILE 和 DELETE_LINE 都不会有值，因此可以不打印 warning。

2．用户的一个实现文件调用了 new 进行内存分配工作，但是该文件并没有使用我们定义的 DEBUG_NEW 宏。同时用户的另一个实现文件中的代码负责调用 delete 来删除前者分配的内存，但不巧的是，这个文件使用了 DEBUG_DELETE 宏。这种情况下内存检测子系统会报告 warning，并打印出 delete 调用的文件名和行号。

3．与第二种情况相反，用户的一个实现文件调用了 new 进行内存分配工作，并使用我们定义的 DEBUG_NEW 宏。同时用户的另一个实现文件中的代码负责调用 delete 来删除前者分配的内存，但该文件没有使用 DEBUG_DELETE 宏。这种情况下，因为我们能够找到这个内存分配的原始信息，所以不会打印 warning。

4． 当出现嵌套 delete（定义可见"实现上的问题"）的情况下，以上第一和第三种情况都有可能打印出不正确的 warning 信息，详细分析可见"实现上的问题"一节。

你可能觉得这样的 warning 太随意了，有误导之嫌。怎么说呢？作为一个检测子系统，对待有可能的错误我们所采取的原则是：宁可误报，不可漏报。请大家"有则改之，无则加勉"。

5．动态内存泄漏信息的检测
上面我们所讲述的内存泄漏的检测能够在程序整个生命周期结束时，打印出在程序运行过程中已经在堆上分配但是没有释放的内存分配信息，程序员可以由此找到程序中"显式"的内存泄漏点并加以改正。但是如果程序在结束之前能够将自己所分配的所有内存都释放掉，是不是就可以说这个程序不存在内存泄漏呢？答案：否！在编程实践中，我们发现了另外两种危害性更大的"隐式"内存泄漏，其表现就是在程序退出时，没有任何内存泄漏的现象，但是在程序运行过程中，内存占用量却不断增加，直到使整个系统崩溃。

1． 程序的一个线程不断分配内存，并将指向内存的指针保存在一个数据存储中（如 list），但是在程序运行过程中，一直没有任何线程进行内存释放。当程序退出的时候，该数据存储中的指针值所指向的内存块被依次释放。

2．程序的N个线程进行内存分配，并将指针传递给一个数据存储，由M个线程从数据存储进行数据处理和内存释放。由于 N 远大于M，或者M个线程数据处理的时间过长，导致内存分配的速度远大于内存被释放的速度。但是在程序退出的时候，数据存储中的指针值所指向的内存块被依次释放。

之所以说他危害性更大，是因为很不容易这种问题找出来，程序可能连续运行几个十几个小时没有问题，从而通过了不严密的系统测试。但是如果在实际环境中 7×24 小时运行，系统将不定时的崩溃，而且崩溃的原因从 log 和程序表象上都查不出原因。

为了将这种问题也挑落马下，我们增加了一个动态检测模块 MemSnapShot，用于在程序运行过程中，每隔一定的时间间隔就对程序当前的内存总使用情况和内存分配情况进行统计，以使用户能够对程序的动态内存分配状况进行监视。

当客户使用 MemSnapShot 进程监视一个运行中的进程时，被监视进程的内存子系统将把内存分配和释放的信息实时传送给MemSnapShot。MemSnapShot 则每隔一定的时间间隔就对所接收到的信息进行统计，计算该进程总的内存使用量，同时以调用new进行内存分配的文件名和行号为索引值，计算每个内存分配动作所分配而未释放的内存总量。这样一来，如果在连续多个时间间隔的统计结果中，如果某文件的某行所分配的内存总量不断增长而始终没有到达一个平衡点甚至回落，那它一定是我们上面所说到的两种问题之一。

在实现上，内存检测子系统的全局对象（appMemory）的构造函数中以自己的当前 PID 为基础 key 值创建一个消息队列，并在operator new 和 operator delete 被调用的时候将相应的信息写入消息队列。MemSnapShot 进程启动时需要输入被检测进程的 PID，而后通过该 PID 组装 key 值并找到被检测进程创建的消息队列，并开始读入消息队列中的数据进行分析统计。当得到operator new 的信息时，记录内存分配信息，当收到 operator delete 消息时，删除相应的内存分配信息。同时启动一个分析线程，每隔一定的时间间隔就计算一下当前的以分配而尚未释放的内存信息，并以内存的分配位置为关键字进行统计，查看在同一位置（相同文件名和行号）所分配的内存总量和其占进程总内存量的百分比。

图4 是一个正在运行的 MemSnapShot 程序，它所监视的进程的动态内存分配情况如图所示：

图四

在支持 MemSnapShot 过程中的实现上的唯一技巧是--对于被检测进程异常退出状况的处理。因为被检测进程中的内存检测子系统创建了用于进程间传输数据的消息队列，它是一个核心资源，其生命周期与内核相同，一旦创建，除非显式的进行删除或系统重启，否则将不被释放。

不错，我们可以在内存检测子系统中的全局对象（appMemory）的析构函数中完成对消息队列的删除，但是如果被检测进程非正常退出（CTRL+C，段错误崩溃等），消息队列可就没人管了。那么我们可以不可以在全局对象（appMemory）的构造函数中使用 signal 系统调用注册 SIGINT，SIGSEGV 等系统信号处理函数，并在处理函数中删除消息队列呢？还是不行，因为被检测进程完全有可能注册自己的对应的信号处理函数，这样就会替换我们的信号处理函数。最终我们采取的方法是利用 fork 产生一个孤儿进程，并利用这个进程监视被检测进程的生存状况，如果被检测进程已经退出（无论正常退出还是异常退出），则试图删除被检测进程所创建的消息队列。下面简述其实现原理：

在全局对象（appMemory）构造函数中，创建消息队列成功以后，我们调用 fork 创建一个子进程，而后该子进程再次调用 fork 创建孙子进程，并退出，从而使孙子进程变为一个"孤儿"进程（之所以使用孤儿进程是因为我们需要切断被检测进程与我们创建的进程之间的信号联系）。孙子进程利用父进程（被检测进程）的全局对象（appMemory）得到其 PID 和刚刚创建的消息队列的标识，并传递给调用 exec 函数产生的一个新的程序映象--MemCleaner。

MemCleaner 程序仅仅调用 kill(pid, 0);函数来查看被检测进程的生存状态，如果被检测进程不存在了（正常或者异常退出），则 kill 函数返回非 0 值，此时我们就动手清除可能存在的消息队列。

6．实现上的问题：嵌套delete
在" 错误方式删除带来的问题"一节中，我们对 delete operator 动了个小手术--增加了两个全局变量（DELETE_FILE,DELETE_LINE）用于记录本次 delete 操作所在的文件名和行号，并且为了同步对全局变量（DELETE_FILE,DELETE_LINE）的访问，增加了一个全局的互斥锁。在一开始，我们使用的是 pthread_mutex_t，但是在测试中，我们发现 pthread_mutex_t 在本应用环境中的局限性。

例如如下代码：

												
														
																
		class B {…};

			class A {
			public:
				A() {m_pB = NULL};
				A(B* pb) {m_pB = pb;};
				~A() 
                                {
                                       if (m_pB != NULL)
           行号1					delete m_pB;		//这句最要命
                                 };
			private:
				class B* m_pB;
				……
			}

		int main()
		{
			A* pA = new A(new B);
			……
          行号2		delete pA;		
                }

												
										

在上述代码中，main 函数中的一句 delete pA 我们称之为"嵌套删除"，即我们 delete A 对象的时候，在A对象的析构执行了另一个 delete B 的动作。当用户使用我们的内存检测子系统时，delete pA 的动作应转化为以下动作：

												
														
																
		上全局锁
	        全局变量（DELETE_FILE,DELETE_LINE）赋值为文件名和行号2
                delete operator A
                  调用~A()
	            上全局锁
	            全局变量（DELETE_FILE,DELETE_LINE）赋值为文件名和行号1
	            delete operator B
		      调用~B()
                      返回~B()
		      调用operator delete B
			记录全局变量（DELETE_FILE,DELETE_LINE）值1并清除全局变量（DELETE_FILE,DELETE_LINE）值
			打开全局锁
		    返回operator delete B
	        返回delete operator B
             返回~A()
         调用 operator delete A
	   记录全局变量（DELETE_FILE,DELETE_LINE）值1并清除全局变量（DELETE_FILE,DELETE_LINE）值
	   打开全局锁
	 返回operator delete A
      返回 delete operator A

												
										

在这一过程中，有两个技术问题，一个是 mutex 的可重入问题，一个是嵌套删除时 对全局变量（DELETE_FILE,DELETE_LINE）现场保护的问题。

所谓 mutex 的可重入问题，是指在同一个线程上下文中，连续对同一个 mutex 调用了多次 lock，然后连续调用了多次 unlock。这就是说我们的应用方式要求互斥锁有如下特性：

1． 要求在同一个线程上下文中，能够多次持有同一个互斥体。并且只有在同一线程上下文中调用相同次数的 unlock 才能放弃对互斥体的占有。

2． 对于不同线程上下文持有互斥体的企图，同一时间只有一个线程能够持有互斥体，并且只有在其释放互斥体之后，其他线程才能持有该互斥体。

Pthread_mutex_t 互斥体不具有以上特性，即使在同一上下文中，第二次调用 pthread_mutex_lock 将会挂起。因此，我们必须实现出自己的互斥体。在这里我们使用 semaphore 的特性实现了一个符合上述特性描述的互斥体 CCommonMutex（源代码见附件）。

为了支持特性 2，在这个 CCommonMutex 类中，封装了一个 semaphore，并在构造函数中令其资源值为 1，初始值为1。当调用 CCommonMutex::lock 接口时，调用 sem_wait 得到 semaphore，使信号量的资源为 0 从而让其他调用 lock 接口的线程挂起。当调用接口 CCommonMutex::unlock 时，调用 sem_post 使信号量资源恢复为 1，让其他挂起的线程中的一个持有信号量。

同时为了支持特性 1，在这个 CCommonMutex 增加了对于当前线程 pid 的判断和当前线程访问计数。当线程第一次调用 lock 接口时，我们调用 sem_wait 的同时，记录当前的 Pid 到成员变量 m_pid，并置访问计数为 1，同一线程（m_pid == getpid()）其后的多次调用将只进行计数而不挂起。当调用 unlock 接口时，如果计数不为 1，则只需递减访问计数，直到递减访问计数为 1 才进行清除 pid、调用 sem_post。（具体代码可见附件）

嵌套删除时对全局变量（DELETE_FILE,DELETE_LINE）现场保护的问题是指，上述步骤中在 A 的析构函数中调用 delete m_pB 时，对全局变量（DELETE_FILE,DELETE_LINE）文件名和行号的赋值将覆盖主程序中调用 delete pA 时对全局变量（DELETE_FILE,DELETE_LINE）的赋值，造成了在执行 operator delete A 时，delete pA 的信息全部丢失。

要想对这些全局信息进行现场保护，最好用的就是堆栈了，在这里我们使用了 STL 提供的 stack 容器。在 DEBUG_DELETE 宏定义中，对全局变量（DELETE_FILE,DELETE_LINE）赋值之前，我们先判断是否前面已经有人对他们赋过值了--观察行号变量是否等于 0，如果不为 0，则应该将已有的信息压栈（调用一个全局函数 BuildStack() 将当前的全局文件名和行号数据压入一个全局堆栈globalStack），而后再对全局变量（DELETE_FILE,DELETE_LINE）赋值，再调用 delete operator。而在内存子系统的全局对象（appMemory）提供的 erase 接口里面，如果判断传入的文件名和行号为 0，则说明我们所需要的数据有可能被嵌套删除覆盖了，所以需要从堆栈中弹出相应的数据进行处理。

现在嵌套删除中的问题基本解决了，但是当嵌套删除与 "错误方式删除带来的问题"一节的最后所描述的第一和第三种异常情况同时出现的时候，由于用户的 delete 调用没有通过我们定义的 DEBUG_DELETE 宏，上述机制可能出现问题。其根本原因是我们利用stack 保留了经由我们的 DEBUG_DELETE 宏记录的 delete 信息的现场，以便在 operator delete 和全局对象（appMemory）的 erase 接口中使用，但是用户的没经过 DEBUG_DELETE 宏的 delete 操作却未曾进行压栈操作而直接调用了 operator delete，有可能将不属于这次操作的 delete 信息弹出，破坏了堆栈信息的顺序和有效性。那么，当我们因为无法找到这次及其后续的 delete 操作所对应的内存分配信息的时候，可能会打印出错误的 warning 信息。

				signal(SIGTTOU,SIG_IGN); 
signal(SIGTTIN,SIG_IGN); 
signal(SIGTSTP,SIG_IGN); 
signal(SIGHUP ,SIG_IGN);
		

　忽略信号。大多数信号都是采取这种方式进行处理的，这里就采用了这种用法。但值得注意的是对SIGKILL和SIGSTOP信号不能做忽略处理。
　捕捉信号。最常见的情况就是，如果捕捉到SIGCHID信号，则表示子进程已经终止。然后可在此信号的捕捉函数中调用waitpid()函数取得该子进程的进程ID和它的终止状态。另外，如果进程创建了临时文件，那么就要为进程终止信号SIGTERM编写一个信号捕捉函数来清除这些临时文件。
　执行系统的默认动作。对绝大多数信号而言，系统的默认动作都是终止该进程。对这些有关终端的信号，一般采用忽略处理，从而保障了终端免受干扰。
　这类信号分别是，SIGTTOU（表示后台进程写控制终端）、SIGTTIN（表示后台进程读控制终端）、SIGTSTP（表示终端挂起）和SIGHUP（进程组长退出时向所有会议成员发出的）。