Fork me on GitHub

my 2017

走过2017，来到2018，这篇文章本来应该再早一点的时候去写，但是因为懒，拖到了现在。

2017，还是非常多的感悟。

成长非常大，收获很多，做了几件想做的事情，完成了几个小目标，当然也有一些想做的事情最终还是没有做，也有几个小目标木有完成，but，终究是轻快地踏进了2018.

2017年初，《造化》撞撞跌跌地走向了第一次正式外测，数据还算不错，就是整个团队开始有点疲惫了，从2016年9月到2016年12月末，基本都是晚上12点后才走，甚至是一两点，第二天早上又早早10点左右就到了，大家都有点疲惫了，但是人手又不够，需求又堆在那里，上线日期渐进，过大的压力让团队部分成员感到疲惫，我们三个负责人还好，本身战斗力强，但是其他人，可能真的是怀着一种打工的心态来做这个项目，而我们三个，虽然之前都还没有合作过，也都比较年轻，但激情都很足，真的是将全部精力都放在了这个项目上面。

但是确实是压力太大了，终于是有团队成员撑不下去撤了，先是客户端开始，赐钱，小龙，来《造化》不过一个多月，就撤了，本身客户端工作量就大，除了杨永之外，书伟战斗力又不够强，服务器就我和华建，华建也渐渐疲惫，子皓又压得紧，华建专业能力又并不是非常强，匆忙赶出来的系统总有bug，于是矛盾开始逐渐积累，而我却在忙碌的工作中，根本没有察觉到这一点，最终华建也还是撤了，临时调振隆过来，振隆本身就已经是不稳定了，来了两周也是撤了，至此，服务器除了我这个负责人，整个都换了一批，而客户端，已经换了两批了。

没有成熟稳定的团队，想做出来成功的项目，无异于痴人说梦。虽然3月份上线前，将整个公司的资源和人员都往《造化》倾斜，将所有人员都抽调过来清掉发下的bug以及遗留的需求，但是此时，《青云诀》已经开始崭露头角，《造化》已经是失败了，在《青云诀》面前，证明了，换皮项目，即便是比较深度的换皮项目，也是不堪一击，天松也是撑不住了，也是在5月初撤了，再过半个月，公司终于是决定，《造化》停止主要的研发工作，全团队转战新项目。

六月初，书伟撤了，杨永小伙子撤了，最初的两个客户端，包括负责人杨永，都撤了。

中途不少我觉得挺不错的人，永舜他们，也撤了很多，我开始反思，为什么一些我觉得挺不错的人，公司都是留不住。

游戏公司加班很正常，但是在光娱，加班应该算是比大多数公司加班要严重不少的，而待遇方面，说实话，与同等公司相比，是要低不少的。压力大，福利待遇跟不上，如果不是作为负责人，如果不是我只是个工作了两年的新人，可能我也早就撤了，最初我不太理解他们，后来才渐渐明白，可能，只是因为我是个工作狂而已。

《造化》整体并入正在开发的新项目中，忙了一整年，终于在6,7月份稍微轻松一点，女朋友规划已久的泰国行提上了日程，提前将所有需求处理好，给自己放了一周假，好好放松放松。

抽空将自己一直想造的服务器框架架构轮子造了出来，开始感觉在光娱的提升开始缓慢，开始对只有工作，没有生活的状态感觉厌倦，最初是打算一直在光娱干下去的，想着做个三五年，能不能成为公司的元老级人物，来点股份分红什么的，虽然已经成为了次元老级人物，但是感觉股份什么的遥遥无期，激励政策几乎为零，福利待遇低市场一个档次，开始渐渐失望，终于是心灰意冷，决定撤了。虽然大家都很想挽留，拓宇也一再暗示我，让我提条件，但终究是累了，在国庆前选择了裸辞。

游戏还是会继续搞的，毕竟兴趣所在，国庆休息完，开始面试，才发现，之前约的面试实在是有点多了，但毕竟是答应了要去，所以还是都去了，两周面了11家，拿了8个offer，除了有个棋牌的不太适合之外，其他两个虽然都到了终面，但不知道最后为啥没给我最终答复。市场缺人是一方面，自己技术过硬，经历丰富也是一方面，当了一次offer收割机，终于是不想再继续面了，在四家主要选项中最终选了游爱网络。

虽然游爱不是待遇给的最高的，但是公司风评较好，双休，而且团队看起来不错，一个五年的项目，居然还能保持月流水将近1kW，让我非常惊讶这个项目的持久力。

来到游爱之后，项目代码比预想的还要再烂一点，开发流程比预想的效率还要低一点，但是居然是 不加班*真 ，氛围不错，老大也放权给我做项目的升级工作。工作强度也远没有光娱大，让我可以在空余时间提升自己，让自己不至于陷入自己没有学习到新东西的焦虑之中，整体感觉都不错，就是项目前景几乎是明朗的，就是不会有太大的前景，但无所谓啦，忙时投入项目，闲时升级项目，学习新技术提升自己是我一直以来的习惯。于是投入到升级项目技术，优化开发流程的工作中，既能兼顾生活，又能投入工作，努力工作，快乐生活，是我一直以来所希望的。

不断接触新技术，不断折腾，转眼就度过了2017后半年，感觉不错。

新的一点，不忘初心，方得始终！

该去吃开年饭了，下午忙里偷闲总结一下2017———all is well.

展开全文 >>

如何解决Mongodb内存过大问题【转】

原文链接：http://blog.csdn.net/wn\_hello/article/details/50956969 一、MongoDB的数据库文件主要有3种： [1]journal 日志文件 跟一些传统数据库不同，MongoDB的日志文件只是用来在系统出现宕机时候恢复尚未来得及同步到硬盘的内存数据。日志文件会存放在一个分开的目录下面。启动时候MongoDB会自动预先创建3个每个为1G的日志文件（初始为空）。除非你真的有持续海量数据并发写入，一般来说3个G已经足够。   [2]namespace 表名文件dbname.ns 这个文件用来存储整个数据库的集合以及索引的名字。这个文件不大，默认16M，可以存储24000个集合或者索引名以及那些集合和索引在数据文件中得具体位置。通过这个文件MongoDB可以知道从哪里去开始寻找或插入集合的数据或者索引数据。   [3]data 数据及索引文件dbname.0, dbname.1,… dbname.n MongoDB的数据以及索引都存放在一个或者多个MongoDB数据文件里。第一个数据文件会以“数据库名.0”命名，如 my-db.0。这个文件默认大小是64M，在接近用完这个64M之前，MongoDB 会提前生成下一个数据文件如my-db.1。数据文件的大小会2倍递增。第二个数据文件的大小为128M，第三个为256M。一直到了2G以后就会停止，一直按这个2G这个大小增加新的文件。   二、在执行db.stats()命令后，得到数据库大小，主要参数为dataSize、storageSize以及fileSize。 [1] dataSize dataSize是最接近真实数据大小的一个参数。你可以用来检查你的数据有多少。这个大小包括了数据库（或者集合）的每条记录的总和。注意每条记录除了BSON文档外还有header及padding这些额外开销。所以实际大小会比真正数据所占空间会稍大。   [2] storageSize 这个参数等于数据库或者某个集合所有用到的Data Extents的总和。注意这个数字会大于dataSize因为Extent里面会有一些删除文档之后留下来的碎片（deleted）。如果有新插入的文档小于或等于碎片的大小，MongoDB会重新利用这个碎片来存储新的文档。不过在这之前这些碎片将一直会被保留在那里占用空间。由于这个原因，你删除文档的时候这个参数不会变小。   [3] fileSize 这个参数只在数据库上有效，指的是实际文件系统中用到的文件的大小。它包括所有的数据Extents的总和，索引Extent的总和，以及一些未被分配的空间。之前提到MongoDB会对数据库文件创建时候进行预分配，例如最小就是64M，哪怕你只有几百个KB的数据。所以这个参数可能会比实际的数据大小会大不少。 这些额外未用空间是用来保证MongoDB可以在新的数据写入时候快速的分配新的Extent，避免引起磁盘空间分配引起的延迟。   三、内存过大解决方案 （1）减小预分配文件的大小

[html] view plain copy

  1. #mongo
  2. >use admin
  3. >db.shutdownServer()
  4. Ctrl+c

  5. mongod –config /etc/mongodb.conf –smallfiles

  6. #mongo
  7. >use dbname
  8. >db.repairDatabase()

  （2）将数据库导入导出

[plain] view plain copy

  1. #mongodump -d databasename
  2. #echo ‘db.dropDatabase()’  mongo databasename
  3. #mongorestore dump/databasename

（3）禁用预分配机制（可能会导致性能降低）

[plain] view plain copy

  1. #mongo
  2. >use admin
  3. >db.shutdownServer()
  4. Ctrl+c

  5. vi /etc/mongodb.conf

  6. 在最后添加「noprealloc = true」

  7. mongod –config /etc/mongodb.conf

  8. #mongo
  9. >use dbname
  10. >db.repairDatabase()

  参考链接： http://stackoverflow.com/questions/2966687/reducing-mongodb-database-file-size http://stackoverflow.com/questions/7147739/mongodb-avoid-excessive-disk-space http://huoding.com/2011/08/19/107 http://281816327.blog.51cto.com/907015/1598460

展开全文 >>

为 C/C++ 项目构建您自己的内存管理器【转】

原文网址：http://blog.csdn.net/qihuaheng/article/details/6755328 简介：  代码的性能优化是一项非常重要的工作。经常可以看到，采用 C 或 C++ 编写的、功能正确的软件在执行时耗费大量的内存、时间、或者在最糟的情况下既耗内存又费时间。作为一名开发人员，可以使用 C/C++ 提供的功能强大的工具来改进处理时间，并且防止内存破坏，这些工具其中之一是控制如何在代码中分配或者释放内存。通过介绍如何针对特定的情况创建自己的内存管理器，本教程对内存管理的相关概念进行了揭秘。 开始之前 了解本教程中包含的内容以及如何最好地利用本教程。 关于本教程 本教程采用了一种基本方法为任何应用程序构建内存管理器。本教程解释了为什么需要内存管理器，并提供了为应用程序编写自定义的内存管理器（以满足特定的需求）的方法。

回页首

目标 在本教程中，您将了解在设计内存管理器之前需要考虑的一些注意事项、可用于创建这种内存管理器的一些特定技术，并在文章的最后了解创建内存管理器的方法。您还将了解各种类型内存管理器设计的优点和不足之处。

回页首

先决条件 本教程面向那些入门级到中级水平的 Linux® 或 UNIX® 程序员。您应该对使用 UNIX 命令行 Shell，以及 C/C++ 语言的应用知识有基本的了解。此外，还需要了解 malloc、calloc、free、memcpy 和 memset 等系统调用（即处理内存分配、释放和内容修改的例程）的内部工作方式。

回页首

系统要求 要运行本教程中的示例，您需要具备安装了 g++ 编译器工具链的 Linux 或者 UNIX 系统。还需要具有足够大的 RAM（大约 256 MB）。 为什么要创建自定义的内存管理器呢？ 要理解内存分配控制如何帮助提高代码的运行速度，首先需要回忆一下 C/C++ 中内存管理的基础知识。C 中的标准库函数malloc、free、calloc 和 realloc，以及 C++ 中的 new、new [ ]、delete 和 delete [ ] 操作符，是这两种语言中内存管理的关键之处。在了解了这一点之后，有几个内容值得注意。 如 malloc 和 new 函数是通用的内存分配器。您的代码可能是单线程的，但它所链接的 malloc 函数同样可以处理多线程的范例。正是由于这个额外功能，使得这些例程的性能有所降低。 在执行时，malloc 和 new 将向操作系统内核请求内存，而 free 和 delete 则请求释放内存。这意味着，操作系统必须_在每次提出内存请求时在用户空间代码和内核代码之间进行切换_。反复调用 malloc 或者 new 的程序，最终将由于不断地进行上下文切换而导致运行缓慢。 对于在程序中分配的、并且以后不再需要使用的内存，常常会忘记对其进行删除，并且 C/C++ 并没有提供自动的垃圾收集。这将导致程序的内存空间占用进一步增长。在实际的大型程序中，性能将受到显著的影响，因为可用内存变得越来越少，并且硬盘访问是非常耗时的。 设计目标 您的内存管理器应该满足下面的设计目标：

  • 速度
  • 健壮性
  • 用户使用便利性
  • 可移植性

速度 与编译器提供的分配器相比，内存管理器的速度必须更快一些。重复的分配和释放不应该降低代码的执行速度。如果可能的话，应该对内存管理器进行优化，以便处理代码中频繁出现的某些分配模式。 健壮性 在程序终止之前，内存管理器必须归还它向系统请求的所有内存。也就是说，不应该存在内存泄漏。它还应该能够处理错误的情况（例如，请求过大的内存），并且很好地解决这些问题。 用户使用便利性 在将内存管理器集成到他们的代码中时，用户应该只需要更改很少的代码。 可移植性 应该可以很容易地将内存管理器移植到其它的系统，并且不应该使用与平台相关的内存管理特性。 创建内存管理器的实用策略 在创建内存管理器时，下面的这些策略是很实用的：

  • 请求较大的内存块。
  • 对常见的请求大小进行优化。
  • 在容器中收集删除的内存。

请求较大的内存块 最常见的内存管理策略之一是，在程序启动期间请求一些较大的内存块，然后在代码执行期间反复地使用它们。可以从这些内存块划出部分内存，以满足各种数据结构的内存分配请求。这将极大地减少系统调用的次数，并提高执行性能。 对常见的请求大小进行优化 在任何程序中，某些特定的请求大小将比其它大小的请求更加常见。如果对您的内存管理器进行优化以便更好地处理这些请求，那么它将工作得更加出色。 在容器中收集删除的内存 应该将程序执行期间删除的内存收集到容器中。然后，应该使用这些容器来满足进一步的内存请求。如果某个请求失败，那么应该将内存访问委托给程序启动期间分配的某个较大的内存块。虽然内存管理最初用于加速程序的执行和防止内存泄漏，但这种技术可能会潜在地导致程序的较低内存空间占用，这是因为它可以重用删除的内存。这是编写您自己的内存分配器的另一个原因！ 分析 C++ new/delete 操作符的执行时间 我们将从一个简单示例开始。假定您的代码使用了一个称为 Complex 的类（该类用于表示复数），并且它使用了 new 和 delete 操作符所提供的机制，如清单 1 中所示。 清单 1. Complex 类的 C++ 代码

class Complex
{
public:
Complex (double a, double b): r (a), c (b) {}
private:
double r; // Real Part
double c; // Complex Part
};

int main(int argc, char* argv[])
{
Complex* array[1000];
for (int i = 0;i < 5000; i++) {
for (int j = 0; j < 1000; j++) {
array[j] = new Complex (i, j);
}
for (int j = 0; j < 1000; j++) {
delete array[j];
}
}
return 0;
}

  外层循环的每次迭代都会导致 1000 次分配和释放。5000 次这样的迭代将导致 10 百万次用户和内核代码之间的切换。在 Solaris 10 计算机中使用 gcc-3.4.6 进行编译之后，执行这个测试程序平均需要花费 3.5 秒。这是编译器提供的全局 new 和 delete 操作符实现的基准性能度量。要为 Complex 类创建自定义的内存管理器以改进编译器的实现，您需要重写 Complex 类特定的 new 和 delete 操作符。 New/Delete：深入研究 在 C++ 中，对内存管理进行组织实际上就是重载 new 或者 delete 操作符。代码中不同的类可能需要使用不同的内存分配策略，这意味着每个类需要特定的 new。否则，必须重写 new 或者 delete 全局操作符。可以采用这两种形式中的任何一种来实现操作符重载，如清单 2 中所示。 清单 2. 重载 new 或者 delete 操作符

void* operator new(size_t size);
void operator delete(void* pointerToDelete);
-OR-
void* operator new(size_t size, MemoryManager& memMgr);
void operator delete(void* pointerToDelete, MemoryManager& memMgr);

  经过重写的 new 操作符负责分配第一个参数中指定大小的原始内存，而 delete 操作符则负责释放这个内存。请注意，这些例程只用于分配或者释放内存；它们并不会分别调用构造函数或析构函数。对于由 new 操作符分配的内存，将调用构造函数，而只有在调用了对象的析构函数后才调用 delete 操作符。 new 的第二种变体是 placement new 操作符，它接受一个 MemoryManager 参数，该参数基本上是为某个对象分配原始内存的数据结构,最后将调用这个对象的构造函数。对于本教程，我们建议使用 new 或者 delete 的第一种变体，因为后一种变体将导致用户代码中MemoryManager& 参数的大量增加，违反了用户使用便利性的设计目标。 我们使用 MemoryManager 类，以便将 new 和 delete 操作符例程作为下面的 MemoryManager 例程的包装，从而进行实际的内存分配或者释放，如清单 3 中所示： MemoryManager gMemoryManager; // Memory Manager, global variable。 清单 3. 作为包装的 new、new[ ]、delete 和 delete[ ] 操作符

MemoryManager gMemoryManager; // Memory Manager, global variable

void* operator new (size_t size)
{
return gMemoryManager.allocate(size);
}

void* operator new[ ] (size_t size)
{
return gMemoryManager.allocate(size);
}

void operator delete (void* pointerToDelete)
{
gMemoryManager.free(pointerToDelete);
}

void operator delete[ ] (void* arrayToDelete)
{
gMemoryManager.free(arrayToDelete);
}

  注意：

  • 传递给 new[ ] 操作符的 size 是数组每个元素的大小与数组元素个数相乘后所得的大小。
  • 这个指针并不是在任何类特定的 new、delete、new[ ] 或者 delete[ ] 操作符中都可以使用。实际上，这四个例程都用作静态方法。您必须在设计过程中始终牢记这一点。
  • 除了使用全局变量来声明内存管理器之外，您当然还可以使用一个单例。

根据到目前为止的介绍，清单 4 显示了内存管理器类的基本接口。 清单 4. 内存管理器接口

class IMemoryManager
{
public:
virtual void* allocate(size_t) = 0;
virtual void free(void*) = 0;
};

class MemoryManager : public IMemoryManager
{
public:
MemoryManager( );
virtual ~MemoryManager( );
virtual void* allocate(size_t);
virtual void free(void*);
};

  我们还倾向于将 allocate 和 free 例程作为内联例程，以便实现更快的分派。 单线程环境中 Complex 类型的第一个内存管理器 我们设计了本教程的第一个内存管理器，并始终牢记到目前为止已经介绍的那些原则。出于简单的考虑，这个自定义的内存管理器专门用于 Complex 类型的对象，并且只能在单线程环境中工作。其基本思想是，在可用的内存管理器中保存 Complex 对象池，并通过这个池来完成以后的分配工作。如果需要创建的 Complex 对象的数目超过了该池中对象的数目，那么将对该池进行扩展。删除的对象将归还到这个池中。图 1 很好地说明了所发生的事件。 图 1. 创建 Complex 对象的池 块图图像 该池中的每个块具有两个用途：

  • 它存储了一个 Complex 对象。
  • 它必须能够将其自身连接到池中的下一个块。

没有选择在 Complex 数据结构中存储一个指针，因为这将增加设计的整体内存空间占用。相比较而言，更好的方法是将 Complex 数据结构的私有变量包装到一个结构中，并将其与 Complex 指针一起创建一个联合。当用作池中的一部分时，这个指针用于指向该池中的下一个空闲元素。当用作独立 Complex 对象时，可以利用该结构来保存实数和复数部分。清单 5 显示了经过修改的数据结构。 清单 5. 经过修改的数据结构，可以在不产生额外开销的情况下存储 Complex*

class Complex
{
public:
Complex (double a, double b): r (a), c (b) {}
private:
union {
struct {
double r; // Real Part
double c; // Complex Part
};
Complex* next;
};
};

  然而，这个策略违反了用户使用便利性的设计目标，因为在集成内存管理器的时候，我们希望在原始数据结构中进行最小限度的更改。为了对此进行改进，我们设计了一个新的 FreeStore 数据结构，它是一个包装数据结构，在保存为池中的一部分时用作指针，否则用作 Complex 对象。清单 6 显示了 FreeStore 对象的数据结构。 清单 6. FreeStore 对象的数据结构

struct FreeStore
{
FreeStore* next;
};

  然后，该池成为 FreeStore 对象的链表，其中每一个都可以指向该池中的下一个元素，并且可以用作一个 Complex 对象。MemoryManager 类必须保存一个指针，以指向这个空闲池第一个元素的头。它应该提供一些用于在需要时扩展池大小的私有方法，以及在程序终止时清空内存的方法。清单 7 包含了经过修改的 Complex 类的数据结构，从而提供 FreeStore 功能。 清单 7. 经过修改的 Complex 类数据结构，其中提供了 FreeStore 功能

#include <sys/types.h>

class MemoryManager: public IMemoryManager
{
struct FreeStore
{
FreeStore *next;
};
void expandPoolSize ();
void cleanUp ();
FreeStore* freeStoreHead;
public:
MemoryManager () {
freeStoreHead = 0;
expandPoolSize ();
}
virtual ~MemoryManager () {
cleanUp ();
}
virtual void* allocate(size_t);
virtual void free(void*);
};

MemoryManager gMemoryManager;

class Complex
{
public:
Complex (double a, double b): r (a), c (b) {}
inline void* operator new(size_t);
inline void operator delete(void*);
private:
double r; // Real Part
double c; // Complex Part
};

  下面是用于内存分配的伪代码：

  1. 如果还没有创建空闲存储，那么创建空闲存储，然后跳转到步骤 3。
  2. 如果空闲存储已经耗尽，则创建一个新的空闲存储。
  3. 返回空闲存储的第一个元素，并且将空闲存储的下一个元素标记为空闲存储的头。

下面是用于内存删除的伪代码：

  1. 让删除指针中的 next 域指向当前空闲存储的头。
  2. 将删除指针标记为空闲存储的头。

清单 8 包含了 Complex 类的 new 和 delete 操作符的源代码。清单 9 显示了空闲存储的扩展和清理方法。问题仍然存在。您能发现具体的问题吗？ 清单 8. 用于 Complex 类的自定义内存分配或者释放

inline void* MemoryManager::allocate(size_t size)
{
if (0 == freeStoreHead)
expandPoolSize ();

FreeStore* head = freeStoreHead;
freeStoreHead = head->next;
return head;
}

inline void MemoryManager::free(void* deleted)
{
FreeStore* head = static_cast <FreeStore*> (deleted);
head->next = freeStoreHead;
freeStoreHead = head;
}

void* Complex::operator new (size_t size)
{
return gMemoryManager.allocate(size);
}

void Complex::operator delete (void* pointerToDelete)
{
gMemoryManager.free(pointerToDelete);
}

  空闲存储的创建并不是那么简单。关键在于理解相同的 FreeStore* 指针还可以用来表示 Complex 对象。因此，单个 FreeStore 指针所需的大小必须是 FreeStore* 或者 Complex 中较大的一个，如清单 9 中所示。 清单 9. 扩展或者清空空闲存储的代码

#define POOLSIZE 32

void MemoryManager::expandPoolSize ()
{
size_t size = (sizeof(Complex) > sizeof(FreeStore*)) ?
sizeof(Complex) : sizeof(FreeStore*);
FreeStore* head = reinterpret_cast <FreeStore*> (new char[size]);
freeStoreHead = head;

for (int i = 0; i < POOLSIZE; i++) {
head->next = reinterpret_cast <FreeStore*> (new char [size]);
head = head->next;
}

head->next = 0;
}

void MemoryManager::cleanUp()
{
FreeStore* nextPtr = freeStoreHead;
for (; nextPtr; nextPtr = freeStoreHead) {
freeStoreHead = freeStoreHead->next;
delete [] nextPtr; // remember this was a char array
}
}

 

有趣的说明

仍然使用全局 new 和 delete 操作符创建空闲存储的元素。然而，您也可以使用 malloc 和 free 的组合。在这两种情况下，执行的平均时间基本相同。

大功告成！您已经为 Complex 类创建了自定义的内存管理器。记得基准测试花费了 3.5 秒。编译并运行相同测试（不需要在主例程中对客户端代码进行任何更改），现在显示执行该程序只需要花费 0.67 秒！为什么存在这样显著的性能改进呢？主要有两个原因：

  • 在用户和内核代码之间的切换数目明显减少，因为它通过将删除的内存收集回空闲存储来重用这些内存。
  • 这个内存管理器是一个适合单线程执行的分配器。我们并不打算在多线程环境中运行这些代码。

之前，我们曾问您是否发现了设计中的问题。这个问题就是，如果没有删除使用 new 创建的 Complex 对象，那么在这种设计中就没有办法回收丢失的内存。如果开发人员使用编译器提供的 new 和 delete 全局操作符，那么情况也是相同的。然而，内存管理器不仅仅涉及性能改进，它还应该能够在设计中避免内存泄漏。对于使用 new 创建的 Complex 对象进行显式删除的情况，cleanUp 例程仅仅将内存返回给操作系统。这个问题只能通过从操作系统中请求更大的内存块（在程序初始化期间）、并对它们进行存储来加以解决。使用 Complex 的 new 操作符从这些块中划出部分内存来响应内存的请求。cleanUp 例程在释放这些块时应该将其作为一个整体，而不是从这些内存块中创建的单个对象。 位图内存管理器 可以在最初的固定大小内存分配方案基础上进行有趣的改进，即位图内存管理器。在这个方案中，向操作系统较大的块进行内存请求，并且通过从这些块划出部分内存来实现内存的分配。通过将整个块作为一个整体来完成释放操作，因而避免了任何潜在的泄漏。这种方法的另一个优点是，它可以支持 new 和 delete 操作的数组版本。 在这种方法中，内存管理器将请求较大的内存块。然后进一步将这个块划分为较小的、且大小固定的内存块。在这种情况下，每个内存块的大小都与 Complex 对象的大小相等。根据这些块中内存块的数目，单独地维护一个位图，以显示每个块的状态（空闲、或者已分配），并且位的数目与内存块的数目相等。当程序请求一个新的 Complex 对象时，内存管理器将根据位图来获得一个空闲块。对于所有的空闲块，将其对应的位设置为 1。对于已使用的块，则将它们对应的位设置为 0。要提供 new[ ] 和 delete[ ] 操作符，您需要维护一个辅助的数据结构，以便在创建或者销毁 Complex 数组对象时帮助跟踪位图中有多少位需要设置为 1 或者 0。 创建一个位图内存管理器 内存管理器从操作系统中请求足够大的内存块。从这个块中划分出部分内存以进行稍后的内存分配。如果请求失败，那么内存管理器将解决这个问题，并将合适的消息传递给用户，表示它已经退出。在这个阶段中，位图中的所有条目都设置为 1。 如果内存管理器耗尽了空闲的内存块，那么它将向操作系统进一步请求较大的内存块。MemoryManager 数据结构中的每个位图都可以用于增大对应的内存块。然而，在调用删除操作之后，用户可以使用对应的块。因此，非连续的删除调用将导致所谓的_分段的内存_，并且可以从这个内存中提供适当大小的块。 清单 10 中给出了 MemoryManager 类的基本结构。它包含 MemoryPoolList，后者保存了从操作系统中请求的内存块的起始地址。对于每个块，在 BitMapEntryList 中都存在一个相应的条目。FreeMapEntries 是一种数据结构，可以用来为 new 调用的非数组版本提高下一个可用空闲块的搜索速度。 清单 10. MemoryManager 类的定义

class MemoryManager : public IMemoryManager
{
std::vector<void*> MemoryPoolList;
std::vector BitMapEntryList;
//the above two lists will maintain one-to-one correspondence and hence
//should be of same size.
std::set<BitMapEntry*> FreeMapEntries;
std::map<void*, ArrayMemoryInfo> ArrayMemoryList;

private:
void* AllocateArrayMemory(size_t size);
void* AllocateChunkAndInitBitMap();
void SetBlockBit(void* object, bool flag);
void SetMultipleBlockBits(ArrayMemoryInfo* info, bool flag);
public:
MemoryManager( ) {}
~MemoryManager( ) {}
void* allocate(size_t);
void free(void*);
std::vector<void*> GetMemoryPoolList();
};

  ArrayMemoryList 保存了为 Complex 对象数组所分配的内存的相关信息。实际上，它是数组的起始地址到结构的映射，以便维护MemPoolListIndex、位图中数组的 StartPosition 和数组的大小，如清单 11 中所示。 清单 11. ArrayInfo 结构定义

typedef struct ArrayInfo
{
int MemPoolListIndex;
int StartPosition;
int Size;
}
ArrayMemoryInfo;

  为了简化位图的操作，将其作为存储某些额外元数据信息的 BitMapEntry 对象来进行维护，如清单 12 中所示。要在位图中设置一个或者多个位，可以使用 SetBit 和 SetMultipleBits 应用程序接口 (API)。FirstFreeBlock() API 可以检索位图所指向的第一个空闲块。 清单 12. BitMapEntry 类定义

typedef struct BitMapEntry
{
int Index;
int BlocksAvailable;
int BitMap[BIT_MAP_SIZE];
public:
BitMapEntry():BlocksAvailable(BIT_MAP_SIZE)
{
memset(BitMap,0xff,BIT_MAP_SIZE / sizeof(char));
// initially all blocks are free and bit value 1 in the map denotes
// available block
}
void SetBit(int position, bool flag);
void SetMultipleBits(int position, bool flag, int count);
void SetRangeOfInt(int* element, int msb, int lsb, bool flag);
Complex* FirstFreeBlock(size_t size);
Complex* ComplexObjectAddress(int pos);
void* Head();
}
BitMapEntry;

  内存管理器将初始化一个“n”位的数组（作为位图），这样一来，这个数组中的每个位对应于所请求的内存的一个块。将所有的条目都设置为 1。这项工作在 BitMapEntry 的构造函数中完成。 在对 Complex 类的 new 或者 malloc 的非数组版本进行调用的过程中，内存管理器将检查 FreeMapEntries 数据结构中是否存在可用的块。如果在其中找到了可用的块，则返回这个块，否则从操作系统中请求一个新的内存块，并设置其对应的 BitMapEntry。从这个块中划出部分内存块返回给用户，将其可用位设置为 0 以表示它不再空闲，并且将指针返回给用户，清单 13 中显示了相关的代码。 清单 13. MemoryManager::allocate 定义

void* MemoryManager::allocate(size_t size)
{
if(size == sizeof(Complex)) // mon-array version
{
std::set<BitMapEntry*>::iterator freeMapI = FreeMapEntries.begin();
if(freeMapI != FreeMapEntries.end())
{
BitMapEntry* mapEntry = *freeMapI;
return mapEntry->FirstFreeBlock(size);
}
else
{
AllocateChunkAndInitBitMap();
FreeMapEntries.insert(&(BitMapEntryList[BitMapEntryList.size() - 1]));
return BitMapEntryList[BitMapEntryList.size() - 1].FirstFreeBlock(size);
}
}
else // array version
{
if(ArrayMemoryList.empty())
{
return AllocateArrayMemory(size);
}
else
{
std::map<void*, ArrayMemoryInfo>::iterator infoI =ArrayMemoryList.begin();
std::map<void*, ArrayMemoryInfo>::iterator infoEndI =
ArrayMemoryList.end();
while(infoI != infoEndI)
{
ArrayMemoryInfo info = (*infoI).second;
if(info.StartPosition != 0) // search only in those mem blocks
continue; // where allocation is done from first byte
else
{
BitMapEntry* entry = &BitMapEntryList[info.MemPoolListIndex];
if(entry->BlocksAvailable < (size / sizeof(Complex)))
return AllocateArrayMemory(size);
else
{
info.StartPosition = BIT_MAP_SIZE - entry->BlocksAvailable;
info.Size = size / sizeof(Complex);
Complex* baseAddress = static_cast<Complex*>(
MemoryPoolList[info.MemPoolListIndex]) + info.StartPosition;

        ArrayMemoryList\[baseAddress\] = info;
        SetMultipleBlockBits(&info, false);

        return baseAddress;
        } 
      }
    }
  }
}

}

  清单 14 中给出了为单个块设置或重置位的代码。 清单 14. MemoryManager::SetBlockBit 定义

void MemoryManager::SetBlockBit(void* object, bool flag)
{
int i = BitMapEntryList.size() - 1;
for (; i >= 0 ; i–)
{
BitMapEntry* bitMap = &BitMapEntryList[i];
if((bitMap->Head <= object )&&
(&(static_cast<Complex*>(bitMap->Head))[BIT_MAP_SIZE-1] >= object))
{
int position = static_cast<Complex*>(object) -
static_cast<Complex*>(bitMap->Head);
bitMap->SetBit(position, flag);
flag ? bitMap->BlocksAvailable++ : bitMap->BlocksAvailable–;
}
}
}

  清单 15 中给出了为多个块设置或重置位的代码。 清单 15. MemoryManager::SetMultipleBlockBit 定义

void MemoryManager::SetMultipleBlockBits(ArrayMemoryInfo* info, bool flag)
{
BitMapEntry* mapEntry = &BitMapEntryList[info->MemPoolListIndex];
mapEntry->SetMultipleBits(info->StartPosition, flag, info->Size);
}

  对于数组版本而言，处理方式有一点不同。用于数组的内存块与那些用于单个对象内存分配的内存块分配自不同的内存块。这减少了在调用两种类型的 new 时搜索下一个空闲可用内存的开销。内存管理器将查找 ArrayMemoryList 数据结构，以获取为数组提供内存的块的有关信息。当找到时，它将获得这个块中的适当部分，将其地址提供给用户，并将相应的位设置为 0。如果出于某种原因而导致操作失败，那么将从操作系统中请求一个新的块，并从中划分出部分内存。两种 new 调用的内存块作为 MemPoolList 的一部分存储在 MemoryManager 类中。 在调用 Complex 类型对象的指针的 delete、或者 free 的非数组版本的过程中，首先确定包含这个指针的内存块（请参见清单 16）。然后，根据这个块的 BitMapEntry 将对应的位重置为 1，从而使其成为可用的块。整个操作将花费 O(1) 时间。对于 delete []，从ArrayMemoryList 中检索相关信息，并且在已知起始位置和位图大小的情况下，将这些位标记为可用。 清单 16. MemoryManager::free 定义

void MemoryManager::free(void* object)
{
if(ArrayMemoryList.find(object) == ArrayMemoryList.end())
SetBlockBit(object, true); // simple block deletion
else
{//memory block deletion
ArrayMemoryInfo *info = &ArrayMemoryList[object];
SetMultipleBlockBits(info, true);
}
}

  下载部分中提供了位图内存管理器代码的完整清单。它是这部分讨论的内存管理器的一个工作示例，并且包括了我们在这个部分中讨论的所有清单。

回页首

继承带来的问题 派生类的大小很可能会与其基类有很大的不同。例如，可以考虑 Complex 类的一个派生变体，称为 ComplexT，它用于跟踪复数的值随时间变化的情况，其中包含一个附加的 unsigned long 用来存储时间。先前重写的 new 或者 delete 操作符现在将无法工作，除非我们专门针对这个派生变体再次定义它们。对于这个问题，有三种可能的解决方案：

  • 使用 MemoryManager 为这两个不同的类维护两个不同的池。实际上，这意味着分配/释放例程的两个变体，以及用来存储这两个池的头的两个指针。这种方式可能奏效，但可伸缩性受到限制。
  • 根据最大的派生类大小维护一个池。allocate 例程始终返回最大派生类的大小，无论是基类、派生类层次中的哪个对象在请求内存。这样可以很好地解决问题，但它并不是一个非常有价值的方法，因为程序的内存空间占用将会增加。
  • 为可变大小的分配创建通用的内存管理器。

基于空闲列表的内存管理器 在一个典型的程序中，内存块的大多数请求都是特定大小的。这个内存管理器将充分利用这个特点。要实现这一点，您需要维护一些列表，其中包含这种大小的空闲块的地址。在技术行话中，我们称这些列表为_空闲列表_。例如，可以考虑某个程序，它将提出 8、16、24、32、48 和 64 字节的内存请求。出于这个目的，内存管理器中包含六个不同的空闲列表，并请求从对应的列表提供特定大小的内存。与位图内存管理器类似，在启动时从操作系统中请求内存，并且内存管理器在内部将从操作系统请求的块划分到各个列表中。在用户为某个对象请求内存时，比如“m”个字节，那么会将对象的大小转换为最接近的块大小“n”，并且存在一个空闲列表用来存储大小为“n”的块。 有关保护字节（guard bytes）的简单介绍 “n”字节的块不仅存储了对象，还存储了一些元数据信息。每个块的末尾附近都包含四个额外的字节，其中包含在堆内存操作范例中称为_保护字节_ 的内容。通常，memcpy 和 memset 函数可以访问所分配内存的界限之外的内存字节。这将导致堆内存的破坏。许多编译器都为所分配的 mem 块添加了一些特殊字符，以充当该块的哨兵（或者保护字节）。对于所分配内存的这些块所进行的任何访问，都将检查所分配的块附近的特殊字符。如果找不到这些字符，那么将认为在程序执行期间以非法的方式更改了它们的值，这暗示堆内存不再处于有序的状态，并且因此受到了破坏。通过这种机制，程序员可以捕获一些所了解的内存错误。在下面的示例中，这四个字节中的其中两个充当了保护字节，第三个字节用于存储这个对象的大小，最后一个字节存储了一个标志，表示这个对象是否可用、或者已经被占用。 创建一个空闲列表内存管理器 如前所述，内存管理器维护了一些指针的列表，这些指针指向可变大小的块。它还对从操作系统请求而来的内存块进行维护，并作为memoryPool。在 MemoryManager 调用其析构函数时，这个池可以用于释放整个内存块。清单 17 显示了该数据结构。 清单 17. 基于空闲列表实现的 MemoryManager 类定义

class MemoryManager : public IMemoryManager
{
private:
VoidPtrList Byte8PtrList;
VoidPtrList Byte16PtrList;
VoidPtrList Byte24PtrList;
VoidPtrList Byte32PtrList;
VoidPtrList Byte40PtrList;
std::vector<void*> MemoryPoolList;

. . . . . . . . . //helper routines may go in here

public:
MemoryManager( ) {}
~MemoryManager( ) {}
void* allocate(size_t);
void free(void*);
};

  我们的示例使用了大小为 16、28 和 32 字节的三个类，因而需要大小为 24、32 和 40 个字节的块来保存它们的保护字节。因此，Byte24PtrList、Byte32PtrList 和 Byte40PtrList 的使用最为频繁，并且代码也主要是和它们相关的。然而，设计相当灵活，也可以用于添加您所希望的其他大小的列表。 为这些类重载了操作符 new 和 delete，它们将调用委派给负责内存分配和释放的 allocate 和 free 例程。下面将详细地介绍这些例程。我们使用了大小为 1024 的块作为对象的初始计数。另外，将示例中使用的每个类的大小作为预定义的常数进行了存储，如清单 18 中所示。 清单 18. 这个实现中所使用的预定义常数

const int JOB_SCHEDULER_SIZE = sizeof(JobScheduler);
const int COMPLEX_SIZE = sizeof(Complex);
const int COORDINATE_SIZE = sizeof(Coordinate);
const int POOL_SIZE = 1024; //number of elements in a single pool
//can be chosen based on application requirements

const int MAX_BLOCK_SIZE = 36; //depending on the application it may change
//In above case it came as 36

  在 allocate 和 free 例程中使用了这些常数。 allocate 例程 对于给定大小的块，allocate 例程将确定使用内存管理器中的哪个列表。它将查找必需的列表，以查看是否存在可用的块。请注意，这个列表仅存储了指向该块的指针，而不是块本身（该块是 MemoryPoolList 的一部分）。 如果空闲列表是空的，那么将从操作系统中请求附加的内存块，并由 InitialiseByte24List、InitialiseByte32List 和InitialiseByte40List 例程将其组织为分区块。 当存在某个空闲块地址可供使用时，将对应的块标记为不可使用，设置其保护字节，并且返回该块的地址。可以考虑如清单 19 中所示的实现。 清单 19. MemoryManager::allocate 定义

void* MemoryManager::allocate(size_t size)
{
void* base = 0;
switch(size)
{
case JOB_SCHEDULER_SIZE :
{
if(Byte32PtrList.empty())
{
base = new char [32 * POOL_SIZE];
MemoryPoolList.push_back(base);
InitialiseByte32List(base);
}
void* blockPtr = Byte32PtrList.front();
*((static_cast<char*>(blockPtr)) + 30) = 32; //size of block set
*((static_cast<char*>(blockPtr)) + 31) = 0; //block is no longer free
Byte32PtrList.pop_front();
return blockPtr;
}
case COORDINATE_SIZE :
{
if(Byte40PtrList.empty())
{
base = new char [40 * POOL_SIZE];
MemoryPoolList.push_back(base);
InitialiseByte40List(base);
}
void* blockPtr = Byte40PtrList.front();
*((static_cast<char*>(blockPtr)) + 38) = 40; //size of block set
*((static_cast<char*>(blockPtr)) + 39) = 0; //block is no longer free
Byte40PtrList.pop_front();
return blockPtr;
}
case COMPLEX_SIZE :
{
if(Byte24PtrList.empty())
{
base = new char [24 * POOL_SIZE];
MemoryPoolList.push_back(base);
InitialiseByte24List(base);
}
void* blockPtr = Byte24PtrList.front();
*((static_cast<char*>(blockPtr)) + 22) = 24; //size of block set
*((static_cast<char*>(blockPtr)) + 23) = 0; //block is no longer free
Byte24PtrList.pop_front();
return blockPtr;
}
default : break;
}
return 0;
}

  free 例程 free 例程接收块的地址，并搜索位于块末尾的、包含大小信息的字节（在保护字节中）。它是块中的倒数第二个字节。在获得这个大小之后，将对象标记为可用（将最后一个字节设置为 1），并获取对应的列表。然后，将该对象加入_空闲_ 列表中，这也标志着完成了删除操作。可以考虑清单 20 中的实现。 清单 20. MemoryManager::free 定义

void MemoryManager::free(void* object)
{
char* init = static_cast<char*>(object);

while(1)
{
int count = 0;
while(*init != static_cast(0xde))
//this loop shall never iterate more than
{ // MAX_BLOCK_SIZE times and hence is O(1)
init++;
if(count > MAX_BLOCK_SIZE)
{
printf (“runtime heap memory corruption near %d”, object);
exit(1);
}
count++;
}
if(*(++init) == static_cast(0xad)) // we have hit the guard bytes
break; // from the outer while
}
init++;
int blockSize = static_cast(*init);
switch(blockSize)
{
case 24: Byte24PtrList.push_front(object); break;
case 32: Byte32PtrList.push_front(object); break;
case 40: Byte40PtrList.push_front(object); break;
default: break;
}
init++;
*init = 1; // set free/available byte
}

  下载部分中提供了空闲列表内存管理器代码的完整清单。它是空闲列表内存管理器实现的一个工作示例，并且包括我们在这个部分中讨论的所有清单。 优点和不足之处 这个设计有下面几个优点：

  • 可以很好地处理可变大小的内存分配。
  • 设计灵活，并且可以通过确定每个软件所需的列表大小来进行扩展。
  • 添加保护字节的能力允许为对象存储大量元数据信息。我们已经将它用于确定运行时堆内存的破坏情况。

虽然这个设计可以显著地改善性能，但它仍然存在不足之处，即它需要大量的内存。 多线程内存管理器 到目前为止，我们所创建的内存管理器并没有考虑到并发的环境。在多线程环境中，可能会有多个线程同时尝试进行内存的分配和释放。这意味着，我们必须确保在内存管理器中进行的分配和释放操作都是具有原子性的。也就是说，在两个线程同时尝试这些操作时，我们必须在这两个线程之间提供一种互斥的机制。要确保分配和释放操作具有原子性，标准的方法是使用一种基于锁的机制。当一个线程调用这两种方法其中之一时，在它实际获得对内存的访问或者释放内存之前，必须获得一个独占锁。如果该锁由另一个线程所拥有，那么将阻塞当前线程，直到它拥有这个锁为止。清单 21 说明了用作锁定机制的函数签名。 清单 21. pthread mutex 方法

#include <pthread.h>

int pthread_mutex_init(pthread_mutex_t *mutex,
const pthread_mutexattr_t *attr);
int pthread_mutex_destroy(pthread_mutex_t *mutex);
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);

  就本文而言，我们使用了标准 Header pthread.h 中定义的 pthread mutexes，GNU 编译器在安装时就提供了这个 Header，以便模拟锁定或者解锁机制。allocation 和 free 例程中的代码位于 pthread_mutex_lock 和 pthread_mutex_unlock 方法之间。如果某个线程正在访问内存池时，又有另一个线程调用了这些例程其中之一，那么它必须等待，直到该锁可用为止。清单 22 是该方法的经过修改的代码片段。 清单 22. 分配和释放方法的并发版本

void* MemoryManager::allocate(size_t size)
{
pthread_mutex_lock (&lock);
… // usual memory allocation code
pthread_mutex_unlock (&lock);
}

void* MemoryManager::free(size_t size)
{
pthread_mutex_lock (&lock);
… // usual memory deallocation code
pthread_mutex_unlock (&lock);
}

  现在，内存管理器类需要包括一个 pthread_mutex_lock 对象。需要修改类构造函数，以便调用 pthread_mutex_init 初始化锁，并且类析构函数必须调用 pthread_mutex_destroy 以销毁 mutex 对象。清单 23 是 MemoryManager 类的修改之后的代码。 清单 23. 经过修改的 MemoryManager 类，以处理多线程的分配和释放

class MemoryManager : public IMemoryManager
{
pthread_mutex_t lock;
… // usual MemoryManager code follows
};

MemoryManager::MemoryManager ()
{
pthread_mutex_init (&lock, NULL);
… // usual constructor code
}

MemoryManager:: ~MemoryManager ()
{
… // usual destructor code
pthread_mutex_destroy (&lock);
}

  现在，运行内存管理器的多线程版本。在我们的测试中，与单线程版本相比，它的运行要慢得多，这说明了为什么需要提供专用的、自定义的内存管理器。 总结 本教程解释了下面的几个概念：

  • 在用户代码中使用内存管理器的需求。
  • 内存管理器的设计需求。
  • 如何创建固定大小的分配器或者内存管理器。
  • 如何创建可变大小的分配器。
  • 多线程环境中的内存分配。

有关这个主题的更多信息，请参见参考资料部分。 下载

描述

名字

大小

下载方法

Source files for bitmapped memory manager

bitmapped_memory_manager.zip

4KB

HTTP

Source files for free-lists based memory manager

free_list_mem_mgr.zip

3KB

HTTP

关于下载方法的信息 参考资料 学习

  • 内存管理参考资料：这个 Ravenbrook Web 站点提供了内存管理方面的介绍。
  • “内存分配器”（Doug Lea）：其中讨论了各种技术和算法。
  • “内存管理内幕”：这篇文章提供了有关内存管理技术的概述，Linux 程序员可以充分地利用这些技术。
  • AIX and UNIX 专区：developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息，您可以利用它们来扩展自己的 UNIX 技能。
  • AIX and UNIX 新手入门：访问“AIX and UNIX 新手入门”页面可了解更多关于 AIX 和 UNIX 的内容。
  • Safari 书店：访问这个电子参考资料库，以查找特定的技术参考资料。
  • developerWorks 技术事件和网络广播：了解最新的 developerWorks 技术事件和网络广播。

获得产品和技术

  • IBM 试用软件：从 developerWorks 可直接下载这些试用软件，您可以利用它们开发您的下一个项目。

讨论

作者简介

developerWorks 投稿作者Arpan 是致力于电子设计自动化行业的软件开发首席工程师。他使用各种 UNIX 版本（包括 Solaris、SunOS、HP-UX、IRIX），以及 Linux 和 Microsoft Windows 已经多年。Arpan 热衷于各种软件性能优化技术、图形理论和并行计算。撰写技术文章为 Arpan 带来了创造性的满足。此外，他还拥有软件系统的硕士学位。

Rahul Kardam 是一名高级软件开发人员，他尤其擅长开发复杂的、基于 C++ 的电子设计自动化工具，如用于硬件设计的仿真器。他在 Windows 和 UNIX 平台方面具有丰富的编程经验。Rahul 很喜欢修改开放源代码软件，并使用它作为健壮的、可伸缩代码的框架，以设计自己使用的自动化工具。

展开全文 >>

boost::asio::io_service::work类【转】

work是一个很小的辅助类，只支持构造函数和析构函数。（还有一个get_io_service返回所关联的io_service） 构造一个work时，outstanding_work_+1，使得io.run在完成所有异步消息后判断outstanding_work_时不会为0，因此会继续调用GetQueuedCompletionStatus并阻塞在这个函数上。 而析构函数中将其-1，并判断其是否为0，如果是，则post退出消息给GetQueuedCompletionStatus让其退出。 因此work如果析构，则io.run会在处理完所有消息之后正常退出。work如果不析构，则io.run会一直运行不退出。如果用户直接调用io.stop，则会让io.run立刻退出。 特别注意的是，work提供了一个拷贝构造函数，因此可以直接在任意地方使用。对于一个io_service来说，有多少个work实例关 联，则outstanding_work_就+1了多少次，只有关联到同一个io_service的work全被 析构之后，io.run才会在所有消息处 理结束之后正常退出。 转自:http://blog.csdn.net/pud\_zha/article/details/37561011

展开全文 >>

c++: mongodb SCRAM-SHA-1 mechanism support not compiled into client library 错误的解决

版本： mongodb 3.4.x mongo-cxx-driver-legacy-1.1.0 编译器： c++11 直接使用驱动的鉴权函数 auth(), 结果报  mongodb SCRAM-SHA-1 mechanism support not compiled into client library. (Some mechanisms require the driver be compiled with the flags –ssl or –use-sasl-client) 这个异常。 如果你就按照提示的这段信息去做，你就被坑了，别问我为什么知道 真实情况是，mongodb的驱动需要初始化，不初始化就会报这个错误，这该死的提示信息。做法如下： 在使用之前调用  mongo::client::initialize();   一次即可，不用重复初始化。 把特~~你以为这就结束了？ 我的调用 mongo 初始化函数之后就挂了~~~ 最后查出来了原因，需要在 mongo-cxx-driver-legacy-1.1.0 编译的时候加 –c++11=on  选项。 OK 都搞定了。 用的时候，记得每次调用 connect() 之后都要 auth() 一下 参考链接 https://stackoverflow.com/questions/28448406/the-authentication-mechanism-scram-sha-1-is-not-supported http://stackoverflow.com/questions/30107966/mongoclientoptionsoptions-at-options-h32   问题原文链接:http://blog.csdn.net/lili861217/article/details/52779920 tips: 如果实在windows下面，如果是默认的，可以不用auth，initalize之后就可以直接用了，如果是在linux下面initalize挂了，就是编译c++ driver的时候，没有加 –c++11=on 选项 测试代码:

using namespace mongo;

void run()
{

mongo::client::initialize();

mongo::DBClientConnection conn;
conn.connect(“127.0.0.1:27017”);

std::string errMsg;
//conn.createCollection(“guang”);

BSONObj p = BSONObjBuilder().append(“name”, “guang”).append(“age”, “26”).obj();

std::string dbName = “guang_test”;
std::string collection = “testCollection”;
std::string tdb = dbName + “.”+collection;

conn.insert(tdb, p);

conn.insert(tdb, p);

conn.insert(tdb, p);

//create databases

conn.createCollection(“hello”);
BSONObj p1 = BSONObjBuilder().append(“hello”, “p1”).obj();

}
void testMongo() {

#ifdef CSG_WIN
WSAData wsaData;
if (WSAStartup(MAKEWORD(1, 1), &wsaData) != 0)
{
return ;
}
#endif

try
{
run();
CSG_LOG_INFO(“conn ok”);
}
catch (const mongo::DBException &e)
{
CSG_LOG_INFO(“caught “ << e.what() );
}
getchar();
return ;
}

删掉CSG_LOG_**,这个是我自己的库的log. 如果win+linux都能正常运行，且mongo里面能读到数据，就说明正常了。

展开全文 >>

jenkins 项目授权策略【转】

默认的Jenkins不包含任何的安全检查，任何人可以修改Jenkins设置，job和启动build等。显然地在大规模的公司需要多个部门一起协调工作的时候，没有任何安全检查会带来很多的问题。 在系统管理－Configure Global Security页面可以“访问控制”进行相应的设置。如下图： Jenkins的权限配置文件存放在JENKINS_HOME目录。进入JENKINS_HOME目录，找到config.xml文件。打开config.xml，里面有一堆的东西，找找。。。找到了和节点。节点代表是否使用用户权限，节点代表用户权限是怎么划分的。 1） Security Realm，用来决定用户名和密码，且指定用户属于哪个组； 2） Authorization Strategy，用来决定用户对那些资源有访问权限；  

一、详细讲解4种授权策略

1、任何用户可以做任何事（没有任何限制） 1）页面设置如下图： 2）config.xml脚本如下：

复制代码

true


true
false

复制代码

  2、登录用户可以做任何事 1）页面设置如下图： 2）config.xml脚本如下：

复制代码

true


false
false

复制代码

  3、安全矩阵 1）页面设置如下图： 2）config.xml脚本如下：

复制代码

true

hudson.model.Hudson.Administer:jenkins
hudson.model.Hudson.Read:anonymous
hudson.model.Hudson.Read:dev
hudson.model.Item.Build:dev
hudson.model.Item.Read:anonymous
hudson.model.Item.Read:dev


false
false

复制代码

设置好权限之后，点击注册，注册相应的账号，如上图的dev,jenkins。   4、项目矩阵授权策略 说明：安全矩阵和项目矩阵授权策略的配置是一模一样的，唯一的区别是项目矩阵授权策略支持在Job的配置页面再次配置授权策略。 这种策略在工作中用得较多，比如针对不同的项目选择不同的用户具有不同权限。 1）页面设置如下图： 各种权限如下(在配置页面将鼠标放到该权限上即可查看帮助)：

Overall(全局)

Credentials(凭证)

Slave(节点)

Job(任务)

View(视图)

Administer

Read

RunScripts

UploadPlugins

ConfigureUpdateCenter

Create

Update

View

Delete

ManageDomains

Configure

Delete

Create

Disconnect

Connect

Build

Create

Delete

Configure

Read

Discover

Build

Workspace

Cancel

Create

Delete

Configure

Read

管理员(最大)

阅读

运行脚本

升级插件

配置升级中心

创建

更新

查看

删除

管理域

配置

删除

创建

断开连接

连接

构建

创建

删除

配置

阅读

重定向

构建

查看工作区

取消构建

创建

删除

配置

阅读

其中有一些比较特别的权限： 最大的权限是Overall的Administer，拥有该权限可以干任何事情。 最基本的权限是Overall的Read，用户必须赋予阅读的权限，不然什么都看不到。 Job的Discover权限是一个奇葩的权限，帮助说Discover比Read的级别更低。如果匿名用户(没有访问job的权限)直接访问一个Job的Url将重定向到登陆页面。(经测试，这个权限应该是被废弃了。) Credentials的ManageDomains这个权限没有看懂干嘛的，有懂的大家一起交流哈！ ps：如果有个用户被赋予了Overall的Read，并没有被赋予Job的Read权限，那么该用户就无法访问job。原因：没有权限。   2）config.xml脚本如下：

复制代码

true

hudson.model.Hudson.Administer:admin
hudson.model.Hudson.Read:anonymous
hudson.model.Item.Build:dev
hudson.model.Item.Read:anonymous
hudson.model.Item.Read:dev


false
false

复制代码

  3）每个用户后都有1-2个图标，第一个是反选功能(删除当前已选择的权限，选择其他所有权限)，第二个是删除功能(删除该用户) 4）在Job中配置项目安全，如下图：  

二、遇到的问题

由于授权出错，导致无法登录，具体可参考http://www.cnblogs.com/yangxia-test/p/4363566.html操作。

最后给大家说说在配置文件里面怎么辨别使用是哪种权限控制模式 节点上有个class属性，这个属性控制着使用那种授权模式。  

hudson.security.FullControlOnceLoggedInAuthorizationStrategy

登录用户可以做任何事

hudson.security.ProjectMatrixAuthorizationStrategy

项目矩阵授权策略

hudson.security.GlobalMatrixAuthorizationStrategy

安全矩阵

hudson.security.LegacyAuthorizationStrategy

遗留模式

展开全文 >>

STL sort 函数实现详解【转】

前几天阿里电话一面，被问到STL中sort函数的实现。以前没有仔细探究过，听人说是快速排序，于是回答说用快速排序实现的，但听电话另一端面试官的声音，感觉不对劲，知道自己回答错了。这几天特意看了一下，在此记录。

函数声明

1
2
3
4
5
6
7
#include <algorithm>
 
template< class RandomIt >
void sort( RandomIt first, RandomIt last );
 
template< class RandomIt, class Compare >
void sort( RandomIt first, RandomIt last, Compare comp );

使用方法非常简单，STL提供了两种调用方式，一种是使用默认的<操作符比较，一种可以自定义比较函数。可是为什么它通常比我们自己写的排序要快那么多呢？

实现原理

原来，STL中的sort并非只是普通的快速排序，除了对普通的快速排序进行优化，它还结合了插入排序和堆排序。根据不同的数量级别以及不同情况，能自动选用合适的排序方法。当数据量较大时采用快速排序，分段递归。一旦分段后的数据量小于某个阀值，为避免递归调用带来过大的额外负荷，便会改用插入排序。而如果递归层次过深，有出现最坏情况的倾向，还会改用堆排序。

普通的快速排序

普通快速排序算法可以叙述如下，假设S代表需要被排序的数据序列：

  1. 如果S中的元素只有0个或1个，结束。
  2. 取S中的任何一个元素作为枢轴pivot。
  3. 将S分割为L、R两端，使L内的元素都小于等于pivot，R内的元素都大于等于pivot。
  4. 对L、R递归执行上述过程。

快速排序最关键的地方在于枢轴的选择，最坏的情况发生在分割时产生了一个空的区间，这样就完全没有达到分割的效果。STL采用的做法称为median-of-three，即取整个序列的首、尾、中央三个地方的元素，以其中值作为枢轴。 分割的方法通常采用两个迭代器head和tail，head从头端往尾端移动，tail从尾端往头端移动，当head遇到大于等于pivot的元素就停下来，tail遇到小于等于pivot的元素也停下来，若head迭代器仍然小于tail迭代器，即两者没有交叉，则互换元素，然后继续进行相同的动作，向中间逼近，直到两个迭代器交叉，结束一次分割。 看一张来自维基百科上关于快速排序的动态图片，帮助理解。

内省式排序 Introsort

不当的枢轴选择，导致不当的分割，会使快速排序恶化为 O(n2)。David R.Musser于1996年提出一种混合式排序算法：Introspective Sorting（内省式排序），简称IntroSort，其行为大部分与上面所说的median-of-three Quick Sort完全相同，但是当分割行为有恶化为二次方的倾向时，能够自我侦测，转而改用堆排序，使效率维持在堆排序的 O(nlgn)，又比一开始就使用堆排序来得好。

代码分析

下面是完整的SGI STL sort()源码（使用默认<操作符版）

1
2
3
4
5
6
7
8
9
10
11
12
template <class _RandomAccessIter>
inline void sort(_RandomAccessIter __first, _RandomAccessIter __last) {
  __STL_REQUIRES(_RandomAccessIter, _Mutable_RandomAccessIterator);
  __STL_REQUIRES(typename iterator_traits<_RandomAccessIter>::value_type,
                 _LessThanComparable);
  if (__first != __last) {
    __introsort_loop(__first, __last,
                     __VALUE_TYPE(__first),
                     __lg(__last - __first) * 2);
    __final_insertion_sort(__first, __last);
  }
}

其中，__introsort_loop便是上面介绍的内省式排序，其第三个参数中所调用的函数__lg()便是用来控制分割恶化情况，代码如下：

1
2
3
4
5
6
template <class Size>
inline Size __lg(Size n) {
    Size k;
    for (k = 0; n > 1; n >>= 1) ++k;
    return k;
}

即求lg(n)（取下整），意味着快速排序的递归调用最多 2*lg(n) 层。 内省式排序算法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
template <class _RandomAccessIter, class _Tp, class _Size>
void __introsort_loop(_RandomAccessIter __first,
                      _RandomAccessIter __last, _Tp*,
                      _Size __depth_limit)
{
  while (__last - __first > __stl_threshold) {
    if (__depth_limit == 0) {
      partial_sort(__first, __last, __last);
      return;
    }
    --__depth_limit;
    _RandomAccessIter __cut =
      __unguarded_partition(__first, __last,
                            _Tp(__median(*__first,
                                         *(__first + (__last - __first)/2),
                                         *(__last - 1))));
    __introsort_loop(__cut, __last, (_Tp*) 0, __depth_limit);
    __last = __cut;
  }
}
  1. 首先判断元素规模是否大于阀值__stl_threshold，__stl_threshold是一个常整形的全局变量，值为16，表示若元素规模小于等于16，则结束内省式排序算法，返回sort函数，改用插入排序。
  2. 若元素规模大于__stl_threshold，则判断递归调用深度是否超过限制。若已经到达最大限制层次的递归调用，则改用堆排序。代码中的partial_sort即用堆排序实现。
  3. 若没有超过递归调用深度，则调用函数__unguarded_partition()对当前元素做一趟快速排序，并返回枢轴位置。__unguarded_partition()函数采用的便是上面所讲的使用两个迭代器的方法，代码如下： 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    template <class _RandomAccessIter, class _Tp>
    _RandomAccessIter __unguarded_partition(_RandomAccessIter __first, 
                                        _RandomAccessIter __last, 
                                        _Tp __pivot) 
    {
    while (true) {
        while (*__first < __pivot)
            ++__first;
        --__last;
        while (__pivot < *__last)
            --__last;
        if (!(__first < __last))
            return __first;
        iter_swap(__first, __last);
        ++__first;
    }
    }
  4. 经过一趟快速排序后，再递归对右半部分调用内省式排序算法。然后回到while循环，对左半部分进行排序。源码写法和我们一般的写法不同，但原理是一样的，需要注意。

递归上述过程，直到元素规模小于__stl_threshold，然后返回sort函数，对整个元素序列调用一次插入排序，此时序列中的元素已基本有序，所以插入排序也很快。至此，整个sort函数运行结束。

结束语

好了，今天就到这里了，相信大家对STL sort也有了一定的了解，如果发现任何错误，欢迎大家批评指正，一起交流！ 原文转自：http://www.cnblogs.com/fengcc/p/5256337.html

展开全文 >>

tcp窗口滑动以及拥塞控制【转】

TCP协议作为一个可靠的面向流的传输协议，其可靠性和流量控制由滑动窗口协议保证，而拥塞控制则由控制窗口结合一系列的控制算法实现。 一、滑动窗口协议 关于这部分自己不晓得怎么叙述才好，因为理解的部分更多，下面就用自己的理解来介绍下TCP的精髓：滑动窗口协议。 所谓滑动窗口协议，自己理解有两点：1. “窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”；2. “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提： -1. TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子； -2. 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区； -3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据； -4. 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送； TCP建立连接的初始，B会告诉A自己的接收窗口大小，比如为‘20’： 字节31-50为发送窗口 A发送11个字节后，发送窗口位置不变，B接收到了乱序的数据分组： 只有当A成功发送了数据，即发送的数据得到了B的确认之后，才会移动滑动窗口离开已发送的数据；同时B则确认连续的数据分组，对于乱序的分组则先接收下来，避免网络重复传递：

二、流量控制 流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。 1. 流量控制 所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送： 这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。 2. 传递效率 一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即： *1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来； *2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去； *3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段； 对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

三、拥塞控制 网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是： 1. 慢开始、拥塞控制 2. 快重传、快恢复 一切的基础还是慢开始，这种方法的思路是这样的： -1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口； -2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文； -3. 当收到第一个字节的数据的确认后，就发送2个字节的报文； -4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级； -5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定： *1. cwnd < ssthresh， 继续使用慢开始算法； *2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法； *3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法； -6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长； -7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）； 上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是： -1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求； -2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包； -3. 此时发送方开始执行“快恢复”算法： *1. 慢开始门限减半； *2. cwnd设为慢开始门限减半后的数值； *3. 执行拥塞避免算法（高起点，线性增长）；

原地址：http://blog.chinaunix.net/uid-26275986-id-4109679.html

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

爱游戏，爱编程，爱捣鼓，爱折腾 技术无极限，乐在其中 人力有穷尽，专注初心 专注于游戏服务器开发 勿忘初心，just  keep  move .