Linux - Tony Bai

标签 Linux 下的文章

Ubuntu Server 14.04安装docker

九月 26, 2014
0 条评论

近期在研究docker这一轻量级容器引擎，研究docker对日常开发测试工作以及产品部署运维工作能带来哪些便利。前些时候刚刚将工作环境从 Ubuntu搬到了Mac Air上，对Mac OS X的一切均不甚熟悉，给docker研究带来了不便，于是打算在VirtualBox中安装一Ubuntu Server作为docker之承载平台。这里记录一下安装配置过程，主要为了备忘，如果能给其他人带来帮助，我会甚感欣慰。

docker官方对ubuntu的支持是蛮好的。docker对Linux内核版本有要求，要>=3.8，Ubuntu Server目前最新版本14.04.1恰符合这一要求，其kernel version = 3.13.0-32。

一、VirtualBox安装Ubuntu Server 14.04.1

VirtualBox安装Ubuntu OS做过了不止一遍，即便是换成最新的14.04.1 Server版，差别也没有太多，无非是按照安装提示，逐步Next。这里给Ubuntu Server 14.04分配了1G Memory, 32G动态硬盘空间。

【配置源】

默认情况下，/etc/apt/sources.list中只有一组源：cn.archive.ubuntu.com/ubuntu。这个国外源的下载速度显然无法满足我的要求，于是我把我常用的sohu源加入sources.list中，并且放在前面：

deb http://mirrors.sohu.com/ubuntu/ trusty main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
deb http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

deb-src http://mirros.sohu.com/ubuntu/ trusty main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
deb-src http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

公司采用代理访问外网，于是还得在/etc/apt/apt.conf中加上代理的设置，否则无法更新源，也就无法安装第三方软件：

Acquire::http::Proxy "http://username:passwd@proxyhost:proxyport";

【乱码处理】

由于安装时候选择了中国区域（locale zh_CN.UTF-8），因此在VirtualBox的窗口中直接执行命令的提示信息可能是乱码。对于Server，我们一般是不会直接通过其主机显示器登录使用的，都是通过终端访问，但在未安装和开启ssh服务和未配置端口转发前，我们只能先凑合这个窗口了。可先将/etc/default /locale中的LANGUAGE由"zh_CN:zh"改为"en_US:en"， logout后重新登录就可以看到非乱码的英文提示信息了。

【安装VirtualBox增强组件】

Ubuntu Server默认是不安装图形桌面的，只有一个命令行窗口，连鼠标都无法使用。因此增强组件安装的意义没有桌面系统那么强烈。我能想到的只有“共享目录”这一个功能有些用处。

安装方法也不难，按下面步骤逐步操作即可：

sudo apt-get install build-essential linux-headers-$(uname -r) dkms gcc g++
sudo mnt /dev/cdrom /mnt
cd /mnt
sudo bash ./VBoxLinuxAdditions.run

如果结果都是"done"，重启后就ok了。

【安装ssh服务】

    ssh服务由openssh-server提供：
    sudo apt-get openssh-server

   安装成功后，ssh server服务就会自动启动起来。

不过我们还是需要修改一些配置，比如允许Root登录：打开/etc/ssh/sshd_config，将PermitRootLogin后面的内容改为yes。

【设置端口转发】

前面说过，对于Server，我们更多是在其他主机上通过ssh或telnet远程访问该Server并执行各种操作。由于这里是VirtualBox安装的虚拟机，其他主机无法看到这台Server，我们需要设置端口转发将外部访问的数据转发给这个内部虚拟Server。

我们通过VirtualBox软件提供的图形界面即可完成这个操作：
    1、“设置”这个虚拟机
    2、在“网络”标签中，点击“端口转发”按钮，进入端口转发规则添加窗口。
    3、添加一条规则：
          名称：ssh-rules
          协议：TCP
          主机IP、子系统IP可以为空。
          主机端口：2222
          子系统端口：22
   4、配置结束

配置结束后，我们在宿主机上netstat -an|grep 2222，可以看到VirtualBox增加了该端口2222的监听。

现在我们就可以在其他机器上通过ssh -l tonybai 宿主机ip -p 2222的方式登录到我们新安装的这台虚拟Server了。

二、安装docker

docker目前的最新版本号是1.2.0，但14.04源中的docker还是正式稳定版1.0之前的版本，显然这是无法满足我的要求的。我们只能另外添加docker源来安装最新版docker。

【安装docker】

    我们在/etc/apt/sources.list中加入下面这个源：
       deb http://mirror.yandex.ru/mirrors/docker/ docker main

    执行apt-get update。

sudo apt-get install lxc-docker

正在读取软件包列表… 完成
正在分析软件包的依赖关系树
正在读取状态信息… 完成
将会安装下列额外的软件包：
aufs-tools cgroup-lite git git-man liberror-perl lxc-docker-1.2.0
建议安装的软件包：
git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk
gitweb git-arch git-bzr git-cvs git-mediawiki git-svn
下列新软件包将被安装：
aufs-tools cgroup-lite git git-man liberror-perl lxc-docker lxc-docker-1.2.0
升级了 0 个软件包，新安装了 7 个软件包，要卸载 0 个软件包，有 59 个软件包未被升级。
需要下载 7,477 kB 的软件包。
解压缩后会消耗掉 35.4 MB 的额外空间。
您希望继续执行吗？ [Y/n] y

这个源里的docker居然是最新版。于是安装之。安装后，我们执行docker version来确认一下安装是否成功。

tonybai@ubuntu-Server-14:~$ docker version
Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): linux/amd64
2014/09/26 13:56:53 Get http:///var/run/docker.sock/v1.14/version: dial unix /var/run/docker.sock: permission denied

【为docker设置http代理】

在公司内使用代理才能访问到外网，于是我们也需要为docker命令设置代理以使其顺利执行命令。

我们安装的docker实际上分为两部分，docker命令行和docker daemon。两者是C/S结构，docker命令行将用户的请求转发给docker daemon，后者会真正与外部通信完成各种操作。

    于是我们可以这样为docker daemon设置http_proxy:
    sudo service docker stop
    sudo http_proxy='http://user:passwd@proxyhost:port' docker -d &

这样设置启动后，我们可以通过下面命令测试设置是否ok：

sudo docker search ubuntu

如果你看到下面信息，说明设置成功了：

    tonybai@ubuntu-Server-14:~$ sudo docker search ubuntu
[info] GET /v1.14/images/search?term=ubuntu
[b36518a9] +job search(ubuntu)
[b36518a9] -job search(ubuntu) = OK (0)
NAME                                             DESCRIPTION                                     STARS                                   OFFICIAL   AUTOMATED
ubuntu                                           Official Ubuntu base image                      709                                     [OK]
dockerfile/ubuntu                                Trusted automated Ubuntu (http://www.ubunt…   24                                                 [OK]
crashsystems/gitlab-docker                       A trusted, regularly updated build of GitL…   20                                                 [OK]
ubuntu-upstart                                   Upstart is an event-based replacement for …   13                                      [OK]
… ….

Cocos2d-x内存管理-绕不过去的坎

三月 18, 2014
2 条评论

Cocos2d-x引擎的核心是用C++编写的，那对于所有使用该引擎的游戏开发人员来说，内存管理是一道绕不过去的坎。

关于Cocos2d-x内存管理，网上已经有了许多参考资料，有些资料写的颇为详实，因为在内存管理这块我不想多费笔墨，只是更多的将思路描述清楚。

一、对象内存引用计数

Cocos2d-x内存管理的基本原理就是对象内存引用计数，Cocos2d-x将内存引用计数的实现放在了顶层父类CCObject中，这里将涉及引用计数的CCObject的成员和方法摘录出来：

class CC_DLL CCObject : public CCCopying
{
public:
   … …
protected:
    // count of references
    unsigned int        m_uReference;
    // count of autorelease
    unsigned int        m_uAutoReleaseCount;
public:
    void release(void);
    void retain(void);
    CCObject* autorelease(void);
    … ….
}

CCObject::CCObject(void)
: m_nLuaID(0)
, m_uReference(1) // when the object is created, the reference count of it is 1
, m_uAutoReleaseCount(0)
{
… …
}

void CCObject::release(void)
{
CCAssert(m_uReference > 0, "reference count should greater than 0");
–m_uReference;

    if (m_uReference == 0)
    {
        delete this;
    }
}

void CCObject::retain(void)
{
CCAssert(m_uReference > 0, "reference count should greater than 0");

++m_uReference;
}

CCObject* CCObject::autorelease(void)
{
CCPoolManager::sharedPoolManager()->addObject(this);
return this;
}

先不考虑autorelease与m_uAutoReleaseCount（后续细说）。计数的核心字段是m_uReference，可以看到：

* 当一个Object初始化（被new出来时），m_uReference = 1；
* 当调用该Object的retain方法时，m_uReference++；
* 当调用该Object的release方法时，m_uReference–，若m_uReference减后为0，则delete该Object。

二、手工对象内存管理

在上述对象内存引用计数的原理下，我们得出以下Cocos2d-x下手工对象内存管理的基本模式：

CCObject *obj = new CCObject();
obj->init();
…. …
obj->release();

在Cocos2d-x中CCDirector就是一个手工内存管理的典型：

CCDirector* CCDirector::sharedDirector(void)
{
    if (!s_SharedDirector)
    {
        s_SharedDirector = new CCDisplayLinkDirector();
        s_SharedDirector->init();
    }

return s_SharedDirector;
}

void CCDirector::purgeDirector()
{
    … …
    // delete CCDirector
    release();
}

三、自动对象内存管理

所谓的“自动对象内存管理”，指的就是哪些不再需要的object将由Cocos2d-x引擎替你释放掉，而无需你手工再调用Release方法。

自动对象内存管理显然也要遵循内存引用计数规则，只有当object的计数变为0时，才会释放掉对象的内存。

自动对象内存管理的典型模式如下：

CCYourClass *CCYourClass::create()
{
    CCYourClass*pRet = new CCYourClass();
    if (pRet && pRet->init())
    {
        pRet->autorelease();
        return pRet;
    }
    else
    {
        CC_SAFE_DELETE(pRet);
        return NULL;
    }
}

一般我们通过一个单例模式创建对象，与手工模式不同的地方在于init后多了一个autorelease调用。这里再把autorelease调用的实现摘录一遍：

CCObject* CCObject::autorelease(void)
{
CCPoolManager::sharedPoolManager()->addObject(this);
return this;
}

追溯addObject方法：

// cocoa/CCAutoreleasePool.cpp

void CCPoolManager::addObject(CCObject* pObject)
{
getCurReleasePool()->addObject(pObject);
}

void CCAutoreleasePool::addObject(CCObject* pObject)
{
m_pManagedObjectArray->addObject(pObject);

    CCAssert(pObject->m_uReference > 1, "reference count should be greater than 1");
    ++(pObject->m_uAutoReleaseCount);
    pObject->release(); // no ref count, in this case autorelease pool added.
}

// cocoa/CCArray.cpp
void CCArray::addObject(CCObject* object)
{
    ccArrayAppendObjectWithResize(data, object);
}

// support/data_support/ccCArray.cpp
void ccArrayAppendObjectWithResize(ccArray *arr, CCObject* object)
{
    ccArrayEnsureExtraCapacity(arr, 1);
    ccArrayAppendObject(arr, object);
}

void ccArrayAppendObject(ccArray *arr, CCObject* object)
{
    CCAssert(object != NULL, "Invalid parameter!");
    object->retain();
    arr->arr[arr->num] = object;
    arr->num++;
}

调用层次挺深，涉及的类也众多，这里归纳总结一下。

Cocos2d-x的自动对象内存管理基于对象引用计数以及CCAutoreleasePool（自动释放池）。引用计数前面已经说过了，这里单说自动释放池。Cocos2d-x关于自动对象内存管理的基本类层次结构如下：

    CCPoolManager类 (自动释放池管理器)
        – CCArray*    m_pReleasePoolStack; （自动释放池栈，存放CCAutoreleasePool类实例）

    CCAutoreleasePool类
        – CCArray*    m_pManagedObjectArray; （受管对象数组）

CCObject关于内存计数以及自动管理有两个字段：m_uReference和m_uAutoReleaseCount。前面在手工管理模式下，我只提及了m_uReference，是m_uAutoReleaseCount该亮相的时候了。我们沿着自动释放对象的创建步骤来看看不同阶段，这两个重要字段的值都是啥，代表的是啥含义：

CCYourClass*pRet = new CCYourClass();    m_uReference = 1； m_uAutoReleaseCount = 0；
pRet->init()；                           m_uReference = 1； m_uAutoReleaseCount = 0；
pRet->autorelease();
    m_pManagedObjectArray->addObject(pObject); m_uReference = 2； m_uAutoReleaseCount = 0；
    ++(pObject->m_uAutoReleaseCount);          m_uReference = 2； m_uAutoReleaseCount = 1；
    pObject->release();                        m_uReference = 1； m_uAutoReleaseCount = 1；

在调用autorelease之前，两个值与手工模式并无差别，在autorelease后，m_uReference值没有变，但m_uAutoReleaseCount被加1。

m_uAutoReleaseCount这个字段的名字很容易让人误解，以为是个计数器，但实际上绝大多数时刻它是一个标识的角色，以前版本代码中有一个布尔字段m_bManaged，似乎后来被m_uAutoReleaseCount替换掉了，因此m_uAutoReleaseCount兼有m_bManaged的含义，也就是说该object是否在自动释放池的控制之下，如果在自动释放池的控制下，自动释放池会定期调用该object的release方法，直到该 object内存计数降为0，被真正释放。否则该object不能被自动释放池自动释放内寸，需手工release。这个理解非常重要，再后面我们能用到这个理解。

四、自动释放时机

通过autorelease我们已经将object放入autoreleasePool中，那究竟何时对象会被释放呢？答案是每帧执行一次自动内存对象释放操作。

在“Hello，Cocos2d-x”一文中，我们讲过整个Cocos2d-x引擎的驱动机制在于GLThread的guardedRun函数，后者会 “死循环”式（实际帧绘制频率受到屏幕vertsym信号的影响）的调用Render的onDrawFrame方法实现，而最终程序会进入 CCDirector::mainLoop方法中，也就是说mainLoop的执行频率是每帧一次。我们再来看看mainLoop的实现：

void CCDisplayLinkDirector::mainLoop(void)
{
    if (m_bPurgeDirecotorInNextLoop)
    {
        m_bPurgeDirecotorInNextLoop = false;
        purgeDirector();
    }
    else if (! m_bInvalid)
     {
         drawScene();

         // release the objects
         CCPoolManager::sharedPoolManager()->pop();
     }
}

这次我们要关注的不是drawScene，而是 CCPoolManager::sharedPoolManager()->pop()，显然在游戏未退出 (m_bPurgeDirecotorInNextLoop决定）的条件下，CCPoolManager的pop方法每帧执行一次，这就是自动释放池执行的起点。

void CCPoolManager::pop()
{
    if (! m_pCurReleasePool)
    {
        return;
    }

int nCount = m_pReleasePoolStack->count();

m_pCurReleasePool->clear();

      if(nCount > 1)
      {
        m_pReleasePoolStack->removeObjectAtIndex(nCount-1);
        m_pCurReleasePool = (CCAutoreleasePool*)m_pReleasePoolStack->objectAtIndex(nCount – 2);
    }
}

真正释放对象的方法是m_pCurReleasePool->clear()。

void CCAutoreleasePool::clear()
{
    if(m_pManagedObjectArray->count() > 0)
    {
        CCObject* pObj = NULL;
        CCARRAY_FOREACH_REVERSE(m_pManagedObjectArray, pObj)
        {
            if(!pObj)
                break;

–(pObj->m_uAutoReleaseCount);
}

m_pManagedObjectArray->removeAllObjects();
}
}

void CCArray::removeAllObjects()
{
    ccArrayRemoveAllObjects(data);
}

void ccArrayRemoveAllObjects(ccArray *arr)
{
    while( arr->num > 0 )
    {
        (arr->arr[--arr->num])->release();
    }
}

不出预料，当前自动释放池遍历每个“受控制”Object，–m_uAutoReleaseCount，并调用该object的release方法。

我们接着按释放流程来看看m_uAutoReleaseCount和m_uReference值的变化：

CCPoolManager::sharedPoolManager()->pop()； m_uReference = 0； m_uAutoReleaseCount = 0；

五、自动释放池的初始化

自动释放池本身是何时出现的呢？回顾一下Cocos2d-x引擎的初始化过程（android版），引擎初始化实在Render的onSurfaceCreated方法中进行的，我们不难追踪到以下代码：

//hellocpp/jni/hellocpp/main.cpp
Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit {

    //这里CCDirector第一次被创建
    if (!CCDirector::sharedDirector()->getOpenGLView())
    {
        CCEGLView *view = CCEGLView::sharedOpenGLView();
        view->setFrameSize(w, h);

        AppDelegate *pAppDelegate = new AppDelegate();
        CCApplication::sharedApplication()->run();
    }
}

CCDirector* CCDirector::sharedDirector(void)
{
    if (!s_SharedDirector)
    {
        s_SharedDirector = new CCDisplayLinkDirector();
        s_SharedDirector->init();
    }

return s_SharedDirector;
}

bool CCDirector::init(void)
{
setDefaultValues();

… …

// create autorelease pool
CCPoolManager::sharedPoolManager()->push();

return true;
}

六、探寻Cocos2d-x内核对象的自动化内存释放

前面我们基本了解了Cocos2D-x的自动化内存释放原理。如果你之前翻看过一些Cocos2d-x的内核源码，你会发现很多内核对象都是通过单例模式create出来的，也就是说都使用了autorelease将自己放入自动化内存释放池中被管理。

比如我们在HelloCpp中看到过这样的代码：

//HelloWorldScene.cpp
bool HelloWorld::init() {
     …. ….
    // add "HelloWorld" splash screen"
    CCSprite* pSprite = CCSprite::create("HelloWorld.png");

// position the sprite on the center of the screen
pSprite->setPosition(ccp(visibleSize.width/2 + origin.x, visibleSize.height/2 + origin.y));

    // add the sprite as a child to this layer
    this->addChild(pSprite, 0);
    … …
}

CCSprite采用自动化内存管理模式create object（cocos2dx/sprite_nodes/CCSprite.cpp），之后将自己加入到HelloWorld这个CCLayer实例中。按照上面的分析，create结束后，CCSprite object的m_uReference = 1； m_uAutoReleaseCount = 1。一旦如此，那么在下一帧时，该object就会被CCPoolManager释放掉。但我们在屏幕上依旧可以看到该Sprite的存在，这是怎么回事呢？

问题的关键就在this->addChild(pSprite, 0)这行代码中。addChild方法实现在CCLayer的父类CCNode中：

// cocos2dx/base_nodes/CCNode.cpp
void CCNode::addChild(CCNode *child, int zOrder, int tag)
{
    … …
    if( ! m_pChildren )
    {
        this->childrenAlloc();
    }

this->insertChild(child, zOrder);

… …
}

void CCNode::insertChild(CCNode* child, int z)
{
    m_bReorderChildDirty = true;
    ccArrayAppendObjectWithResize(m_pChildren->data, child);
    child->_setZOrder(z);
}

void ccArrayAppendObjectWithResize(ccArray *arr, CCObject* object)
{
ccArrayEnsureExtraCapacity(arr, 1);
ccArrayAppendObject(arr, object);
}

void ccArrayAppendObject(ccArray *arr, CCObject* object)
{
    CCAssert(object != NULL, "Invalid parameter!");
    object->retain();
    arr->arr[arr->num] = object;
    arr->num++;
}

又是一系列方法调用，最终我们来到了ccArrayAppendObject方法中，看到了陌生而又眼熟的retain方法调用。

在本文开始我们介绍CCObject时，我们知道retain是CCObject的一个方法，用于增加m_uReference计数。而实际上retain还隐含着“保留”这层意思。

在完成this->addChild(pSprite, 0)调用后，CSprite object的m_uReference = 2； m_uAutoReleaseCount = 1，这很关键。

我们在脑子里再过一下自动释放池释放object的过程：–m_uReference, –m_uAutoReleaseCount。一帧之后，两个值变成了m_uReference = 1； m_uAutoReleaseCount = 0。还记得前面说过的m_uAutoReleaseCount的另外一个非计数含义么，那就是表示该object是否“受控”，现在值为0，显然不再受自动释放池的控制了，后续即便再执行100次内存自动释放，也不会影响到该object的存活。

后续要想释放这个“精灵”，我们还是需要手工调用release，或再调用其autorelease方法。