今天学习新建了一个物料，结果创建订单时只能在一个工厂用，想将其加到其它工厂中，试了N遍不得其解，请教内部专家后找到原因；

SAP中维护物料主数据到多个工厂，使用MM01代码，输入物料号，选择新的工厂，重新创建一次，有N个工厂要用就要维护N次；

前几日早上打开邮箱收到一封监控报警邮件：某某 ip 服务器 CPU 负载较高，请研发尽快排查解决，发送时间正好是凌晨。

其实早在去年我也处理过类似的问题，并记录下来：《一次生产 CPU 100% 排查优化实践》

不过本次问题产生的原因却和上次不太一样，大家可以接着往下看。

问题分析

收到邮件后我马上登陆那台服务器，看了下案发现场还在（负载依然很高）。

于是我便利用这类问题的排查套路定位一遍。

首先利用 top -c 将系统资源使用情况实时显示出来 （-c 参数可以完整显示命令）。

接着输入大写 P 将应用按照 CPU 使用率排序，第一个就是使用率最高的程序。

果不其然就是我们的一个 Java 应用。

这个应用简单来说就是定时跑一些报表使的，每天凌晨会触发任务调度，正常情况下几个小时就会运行完毕。

常规操作第二步自然是得知道这个应用中最耗 CPU 的线程到底再干嘛。

利用 top -Hp pid 然后输入 P 依然可以按照 CPU 使用率将线程排序。

这时我们只需要记住线程的 ID 将其转换为 16 进制存储起来，通过 jstack pid >pid.log 生成日志文件，利用刚才保存的 16 进制进程 ID 去这个线程快照中搜索即可知道消耗 CPU 的线程在干啥了。

如果你嫌麻烦，我也强烈推荐阿里开源的问题定位神器 arthas 来定位问题。

比如上述操作便可精简为一个命令 thread -n 3 即可将最忙碌的三个线程快照打印出来，非常高效。

更多关于 arthas 使用教程请参考官方文档。

由于之前忘记截图了，这里我直接得出结论吧：

最忙绿的线程是一个 GC 线程，也就意味着它在忙着做垃圾回收。

GC 查看

排查到这里，有经验的老司机一定会想到：多半是应用内存使用有问题导致的。

于是我通过 jstat -gcutil pid 200 50 将内存使用、gc 回收状况打印出来（每隔 200ms 打印 50次）。

从图中可以得到以下几个信息：

• Eden 区和 old 区都快占满了，可见内存回收是有问题的。

• fgc 回收频次很高，10s 之内发生了 8 次回收（(866493-866485)/ (200 *5)）。

• 持续的时间较长，fgc 已经发生了 8W 多次。

内存分析

既然是初步定位是内存问题，所以还是得拿一份内存快照分析才能最终定位到问题。

通过命令 jmap -dump:live,format=b,file=dump.hprof pid 可以导出一份快照文件。

这时就得借助 MAT 这类的分析工具出马了。

问题定位

通过这张图其实很明显可以看出，在内存中存在一个非常大的字符串，而这个字符串正好是被这个定时任务的线程引用着。

大概算了一下这个字符串所占的内存为 258m 左右，就一个字符串来说已经是非常大的对象了。

那这个字符串是咋产生的呢？

其实看上图中的引用关系及字符串的内容不难看出这是一个 insert 的 SQL 语句。

这时不得不赞叹 MAT 这个工具，他还能帮你预测出这个内存快照可能出现问题地方同时给出线程快照。

最终通过这个线程快照找到了具体的业务代码：

他调用一个写入数据库的方法，而这个方法会拼接一个 insert 语句，其中的 values 是循环拼接生成，大概如下：

    <insert id="insert" parameterType="java.util.List">
        insert into xx (files)
        values        <foreach collection="list" item="item" separator=",">
            xxx        </foreach>
    </insert>

所以一旦这个 list 非常大时，这个拼接的 SQL 语句也会很长。

通过刚才的内存分析其实可以看出这个 List 也是非常大的，也就导致了最终的这个 insert 语句占用的内存巨大。

优化策略

既然找到问题原因那就好解决了，有两个方向：

• 控制源头 List 的大小，这个 List 也是从某张表中获取的数据，可以分页获取；这样后续的 insert 语句就会减小。

• 控制批量写入数据的大小，其实本质还是要把这个拼接的 SQL 长度降下来。

• 整个的写入效率需要重新评估。

总结

本次问题从分析到解决花的时间并不长，也还比较典型，其中的过程再总结一下：

• 首先定位消耗 CPU 进程。

• 再定位消耗 CPU 的具体线程。

• 内存问题 dump 出快照进行分析。

• 得出结论，调整代码，测试结果。

最后愿大家都别接到生产告警。

scrapy 是一个为了爬取网站数据，提取结构性数据而编写的应用框架。关于框架使用的更多详情可浏览官方文档，本篇文章展示的是爬取漫画图片的大体实现过程。

首先是 scrapy 的安装，博主用的是Mac系统，直接运行命令行：

pip install Scrapy

对于html节点信息的提取使用了 Beautiful Soup 库，大概的用法可见之前的一篇文章，直接通过命令安装：

pip install beautifulsoup4

对于目标网页的 Beautiful Soup 对象初始化需要用到 html5lib 解释器，安装的命令：

pip install html5lib

安装完成后，直接在命令行运行命令：

scrapy

可以看到如下输出结果，这时候证明scrapy安装完成了。

Scrapy 1.2.1 - no active project
Usage: scrapy <command> [options] [args]
Available commands: bench         Run quick benchmark test commands fetch         Fetch a URL using the Scrapy downloader genspider     Generate new spider using pre-defined templates runspider     Run a self-contained spider (without creating a project) settings      Get settings values  ...

scrapy startproject Comics

|____Comics| |______init__.py| |______pycache__| |____items.py| |____pipelines.py| |____settings.py| |____spiders| | |______init__.py| | |______pycache__|____scrapy.cfg

find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'

1、创建Spider类

#coding:utf-8
import scrapy
class Comics(scrapy.Spider):
   name = "comics"
   def start_requests(self):       urls = ['http://www.xeall.com/shenshi']       for url in urls:           yield scrapy.Request(url=url, callback=self.parse)
   def parse(self, response):       self.log(response.body);

scrapy crawl comics

2016-11-26 22:04:35 [scrapy] INFO: Scrapy 1.2.1 started (bot: Comics)2016-11-26 22:04:35 [scrapy] INFO: Overridden settings: {'ROBOTSTXT_OBEY': True, 'BOT_NAME': 'Comics', 'NEWSPIDER_MODULE': 'Comics.spiders', 'SPIDER_MODULES': ['Comics.spiders']}2016-11-26 22:04:35 [scrapy] INFO: Enabled extensions:['scrapy.extensions.corestats.CoreStats', 'scrapy.extensions.telnet.TelnetConsole', 'scrapy.extensions.logstats.LogStats'] ...

1、起始地址

http://www.xeall.com/shenshi

scrapy.Request(url=url, callback=self.parse)

#coding:utf-8
import scrapy
class Comics(scrapy.Spider):
   name = "comics"   start_urls = ['http://www.xeall.com/shenshi']
   def parse(self, response):       self.log(response.body);

2、爬取漫画url

当前页漫画列表

from bs4 import BeautifulSoup

def parse(self, response):    content = response.body;    soup = BeautifulSoup(content, "html5lib")

listcon_tag = soup.find('ul', class_='listcon')

com_a_list = listcon_tag.find_all('a', attrs={'href': True})

comics_url_list = []base = 'http://www.xeall.com'    for tag_a in com_a_list:        url = base + tag_a['href']        comics_url_list.append(url)

3、下一页列表

page_tag = soup.find('ul', class_='pagelist')page_a_list = page_tag.find_all('a', attrs={'href': True})

select_tag = soup.find('select', attrs={'name': 'sldd'})option_list = select_tag.find_all('option')
last_option = option_list[-1]current_option = select_tag.find('option' ,attrs={'selected': True})
is_last = (last_option.string == current_option.string)

if not is_last:    next_page = 'http://www.xeall.com/shenshi/' + page_a_list[-2]['href']    if next_page is not None:        print('\n------ parse next page --------')        print(next_page)        yield scrapy.Request(next_page, callback=self.parse)

4、爬取漫画图片

for url in comics_url_list:    yield scrapy.Request(url=url, callback=self.comics_parse)

5、当前页图片

def comics_parse(self, response):    content = response.body;    soup = BeautifulSoup(content, "html5lib")

page_list_tag = soup.find('ul', class_='pagelist')

current_li = page_list_tag.find('li', class_='thisclass')page_num = current_li.a.string

li_tag = soup.find('li', id='imgshow')img_tag = li_tag.find('img')
img_url = img_tag['src']title = img_tag['alt']

self.save_img(page_num, title, img_url)

# 先导入库import osimport urllibimport zlib
def save_img(self, img_mun, title, img_url):   # 将图片保存到本地   self.log('saving pic: ' + img_url)
   # 保存漫画的文件夹   document = '/Users/moshuqi/Desktop/cartoon'
   # 每部漫画的文件名以标题命名   comics_path = document + '/' + title   exists = os.path.exists(comics_path)   if not exists:       self.log('create document: ' + title)       os.makedirs(comics_path)
   # 每张图片以页数命名   pic_name = comics_path + '/' + img_mun + '.jpg'
   # 检查图片是否已经下载到本地，若存在则不再重新下载   exists = os.path.exists(pic_name)   if exists:       self.log('pic exists: ' + pic_name)       return
   try:       user_agent = 'Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)'       headers = { 'User-Agent' : user_agent }
       req = urllib.request.Request(img_url, headers=headers)       response = urllib.request.urlopen(req, timeout=30)
       # 请求返回到的数据       data = response.read()
       # 若返回数据为压缩数据需要先进行解压       if response.info().get('Content-Encoding') == 'gzip':           data = zlib.decompress(data, 16 + zlib.MAX_WBITS)
       # 图片保存到本地       fp = open(pic_name, "wb")       fp.write(data)       fp.close
       self.log('save image finished:' + pic_name)
   except Exception as e:       self.log('save image error.')       self.log(e)

7、下一页图片

a_tag_list = page_list_tag.find_all('a')next_page = a_tag_list[-1]['href']if next_page == '#':    self.log('parse comics:' + title + 'finished.')else:    next_page = 'http://www.xeall.com/shenshi/' + next_page    yield scrapy.Request(next_page, callback=self.comics_parse)

yield scrapy.Request(next_page, callback=self.comics_parse)

1、智能指针的作用

C++程序设计中使用堆内存是非常频繁的操作，堆内存的申请和释放都由程序员自己管理。程序员自己管理堆内存可以提高了程序的效率，但是整体来说堆内存的管理是麻烦的，C++11中引入了智能指针的概念，方便管理堆内存。使用普通指针，容易造成堆内存泄露（忘记释放），二次释放，程序发生异常时内存泄露等问题等，使用智能指针能更好的管理堆内存。

理解智能指针需要从下面三个层次：

1、从较浅的层面看，智能指针是利用了一种叫做RAII（资源获取即初始化）的技术对普通的指针进行封装，这使得智能指针实质是一个对象，行为表现的却像一个指针。

2、智能指针的作用是防止忘记调用delete释放内存和程序异常的进入catch块忘记释放内存。另外指针的释放时机也是非常有考究的，多次释放同一个指针会造成程序崩溃，这些都可以通过智能指针来解决。

3、智能指针还有一个作用是把值语义转换成引用语义。C++和Java有一处最大的区别在于语义不同，在Java里面下列代码：

Animal a = new Animal();
Animal b = a;

你当然知道，这里其实只生成了一个对象，a和b仅仅是把持对象的引用而已。但在C++中不是这样，

Animal a;
Animal b = a;

这里却是就是生成了两个对象。

关于值语言参考这篇文章http://www.cnblogs.com/Solstice/archive/2011/08/16/2141515.html

2、智能指针的使用

智能指针在C++11版本之后提供，包含在头文件中，shared_ptr、unique_ptr、weak_ptr

2.1 shared_ptr的使用

shared_ptr多个指针指向相同的对象。shared_ptr使用引用计数，每一个shared_ptr的拷贝都指向相同的内存。每使用他一次，内部的引用计数加1，每析构一次，内部的引用计数减1，减为0时，自动删除所指向的堆内存。shared_ptr内部的引用计数是线程安全的，但是对象的读取需要加锁。

• 初始化。智能指针是个模板类，可以指定类型，传入指针通过构造函数初始化。也可以使用make_shared函数初始化。不能将指针直接赋值给一个智能指针，一个是类，一个是指针。例如std::shared_ptr p4 = new int(1);的写法是错误的

• 拷贝和赋值。拷贝使得对象的引用计数增加1，赋值使得原对象引用计数减1，当计数为0时，自动释放内存。后来指向的对象引用计数加1，指向后来的对象

• get函数获取原始指针

• 注意不要用一个原始指针初始化多个shared_ptr，否则会造成二次释放同一内存

• 注意避免循环引用，shared_ptr的一个最大的陷阱是循环引用，循环，循环引用会导致堆内存无法正确释放，导致内存泄漏。循环引用在weak_ptr中介绍。

  
  

#include <iostream>
#include <memory>

int main() {
    {
        int a = 10;
        std::shared_ptr<int> ptra = std::make_shared<int>(a);
        std::shared_ptr<int> ptra2(ptra); //copy
        std::cout << ptra.use_count() << std::endl;

        int b = 20;
        int *pb = &a;
        //std::shared_ptr<int> ptrb = pb;  //error
        std::shared_ptr<int> ptrb = std::make_shared<int>(b);
        ptra2 = ptrb; //assign
        pb = ptrb.get(); //获取原始指针

        std::cout << ptra.use_count() << std::endl;
        std::cout << ptrb.use_count() << std::endl;
    }
}

2.2 unique_ptr的使用

unique_ptr“唯一”拥有其所指对象，同一时刻只能有一个unique_ptr指向给定对象（通过禁止拷贝语义、只有移动语义来实现）。相比与原始指针unique_ptr用于其RAII的特性，使得在出现异常的情况下，动态资源能得到释放。unique_ptr指针本身的生命周期：从unique_ptr指针创建时开始，直到离开作用域。离开作用域时，若其指向对象，则将其所指对象销毁(默认使用delete操作符，用户可指定其他操作)。unique_ptr指针与其所指对象的关系：在智能指针生命周期内，可以改变智能指针所指对象，如创建智能指针时通过构造函数指定、通过reset方法重新指定、通过release方法释放所有权、通过移动语义转移所有权。

#include <iostream>
#include <memory>

int main() {
    {
        std::unique_ptr<int> uptr(new int(10));  //绑定动态对象
        //std::unique_ptr<int> uptr2 = uptr;  //不能賦值
        //std::unique_ptr<int> uptr2(uptr);  //不能拷貝
        std::unique_ptr<int> uptr2 = std::move(uptr); //轉換所有權
        uptr2.release(); //释放所有权
    }
    //超過uptr的作用域，內存釋放
}

2.3 weak_ptr的使用

weak_ptr是为了配合shared_ptr而引入的一种智能指针，因为它不具有普通指针的行为，没有重载operator*和->,它的最大作用在于协助shared_ptr工作，像旁观者那样观测资源的使用情况。weak_ptr可以从一个shared_ptr或者另一个weak_ptr对象构造，获得资源的观测权。但weak_ptr没有共享资源，它的构造不会引起指针引用计数的增加。使用weak_ptr的成员函数use_count()可以观测资源的引用计数，另一个成员函数expired()的功能等价于use_count()==0,但更快，表示被观测的资源(也就是shared_ptr的管理的资源)已经不复存在。weak_ptr可以使用一个非常重要的成员函数lock()从被观测的shared_ptr获得一个可用的shared_ptr对象， 从而操作资源。但当expired()==true的时候，lock()函数将返回一个存储空指针的shared_ptr。

#include <iostream>
#include <memory>

int main() {
    {
        std::shared_ptr<int> sh_ptr = std::make_shared<int>(10);
        std::cout << sh_ptr.use_count() << std::endl;

        std::weak_ptr<int> wp(sh_ptr);
        std::cout << wp.use_count() << std::endl;

        if(!wp.expired()){
            std::shared_ptr<int> sh_ptr2 = wp.lock(); //get another shared_ptr
            *sh_ptr = 100;
            std::cout << wp.use_count() << std::endl;
        }
    }
    //delete memory
}

2.4 循环引用

考虑一个简单的对象建模——家长与子女：a Parent has a Child, a Child knowshis/her Parent。在Java 里边很好写，不用担心内存泄漏，也不用担心空悬指针，只要正确初始化myChild 和myParent，那么Java 程序员就不用担心出现访问错误。一个handle 是否有效，只需要判断其是否non null。

public class Parent
{
　　private Child myChild;
}
public class Child
{
　　private Parent myParent;
}

在C++里边就要为资源管理费一番脑筋。如果使用原始指针作为成员，Child和Parent由谁释放？那么如何保证指针的有效性？如何防止出现空悬指针？这些问题是C++面向对象编程麻烦的问题，现在可以借助smart pointer把对象语义（pointer）转变为值（value）语义，shared_ptr轻松解决生命周期的问题，不必担心空悬指针。但是这个模型存在循环引用的问题，注意其中一个指针应该为weak_ptr。

原始指针的做法，容易出错

#include <iostream>
#include <memory>

class Child;
class Parent;

class Parent {
private:
    Child* myChild;
public:
    void setChild(Child* ch) {
        this->myChild = ch;
    }

    void doSomething() {
        if (this->myChild) {

        }
    }

    ~Parent() {
        delete myChild;
    }
};

class Child {
private:
    Parent* myParent;
public:
    void setPartent(Parent* p) {
        this->myParent = p;
    }
    void doSomething() {
        if (this->myParent) {

        }
    }
    ~Child() {
        delete myParent;
    }
};

int main() {
    {
        Parent* p = new Parent;
        Child* c =  new Child;
        p->setChild(c);
        c->setPartent(p);
        delete c;  //only delete one
    }
    return 0;
}

循环引用内存泄露的问题

#include <iostream>
#include <memory>

class Child;
class Parent;

class Parent {
private:
    std::shared_ptr<Child> ChildPtr;
public:
    void setChild(std::shared_ptr<Child> child) {
        this->ChildPtr = child;
    }

    void doSomething() {
        if (this->ChildPtr.use_count()) {

        }
    }

    ~Parent() {
    }
};

class Child {
private:
    std::shared_ptr<Parent> ParentPtr;
public:
    void setPartent(std::shared_ptr<Parent> parent) {
        this->ParentPtr = parent;
    }
    void doSomething() {
        if (this->ParentPtr.use_count()) {

        }
    }
    ~Child() {
    }
};

int main() {
    std::weak_ptr<Parent> wpp;
    std::weak_ptr<Child> wpc;
    {
        std::shared_ptr<Parent> p(new Parent);
        std::shared_ptr<Child> c(new Child);
        p->setChild(c);
        c->setPartent(p);
        wpp = p;
        wpc = c;
        std::cout << p.use_count() << std::endl; // 2
        std::cout << c.use_count() << std::endl; // 2
    }
    std::cout << wpp.use_count() << std::endl;  // 1
    std::cout << wpc.use_count() << std::endl;  // 1
    return 0;
}

正确的做法

#include <iostream>
#include <memory>

class Child;
class Parent;

class Parent {
private:
    //std::shared_ptr<Child> ChildPtr;
    std::weak_ptr<Child> ChildPtr;
public:
    void setChild(std::shared_ptr<Child> child) {
        this->ChildPtr = child;
    }

    void doSomething() {
        //new shared_ptr
        if (this->ChildPtr.lock()) {

        }
    }

    ~Parent() {
    }
};

class Child {
private:
    std::shared_ptr<Parent> ParentPtr;
public:
    void setPartent(std::shared_ptr<Parent> parent) {
        this->ParentPtr = parent;
    }
    void doSomething() {
        if (this->ParentPtr.use_count()) {

        }
    }
    ~Child() {
    }
};

int main() {
    std::weak_ptr<Parent> wpp;
    std::weak_ptr<Child> wpc;
    {
        std::shared_ptr<Parent> p(new Parent);
        std::shared_ptr<Child> c(new Child);
        p->setChild(c);
        c->setPartent(p);
        wpp = p;
        wpc = c;
        std::cout << p.use_count() << std::endl; // 2
        std::cout << c.use_count() << std::endl; // 1
    }
    std::cout << wpp.use_count() << std::endl;  // 0
    std::cout << wpc.use_count() << std::endl;  // 0
    return 0;
}

3、智能指针的设计和实现

下面是一个简单智能指针的demo。智能指针类将一个计数器与类指向的对象相关联，引用计数跟踪该类有多少个对象共享同一指针。每次创建类的新对象时，初始化指针并将引用计数置为1；当对象作为另一对象的副本而创建时，拷贝构造函数拷贝指针并增加与之相应的引用计数；对一个对象进行赋值时，赋值操作符减少左操作数所指对象的引用计数（如果引用计数为减至0，则删除对象），并增加右操作数所指对象的引用计数；调用析构函数时，构造函数减少引用计数（如果引用计数减至0，则删除基础对象）。智能指针就是模拟指针动作的类。所有的智能指针都会重载 -> 和 * 操作符。智能指针还有许多其他功能，比较有用的是自动销毁。这主要是利用栈对象的有限作用域以及临时对象（有限作用域实现）析构函数释放内存。

 1 #include <iostream>
 2 #include <memory>
 3 
 4 template<typename T>
 5 class SmartPointer {
 6 private:
 7     T* _ptr;
 8     size_t* _count;
 9 public:
10     SmartPointer(T* ptr = nullptr) :
11             _ptr(ptr) {
12         if (_ptr) {
13             _count = new size_t(1);
14         } else {
15             _count = new size_t(0);
16         }
17     }
18 
19     SmartPointer(const SmartPointer& ptr) {
20         if (this != &ptr) {
21             this->_ptr = ptr._ptr;
22             this->_count = ptr._count;
23             (*this->_count)++;
24         }
25     }
26 
27     SmartPointer& operator=(const SmartPointer& ptr) {
28         if (this->_ptr == ptr._ptr) {
29             return *this;
30         }
31 
32         if (this->_ptr) {
33             (*this->_count)--;
34             if (this->_count == 0) {
35                 delete this->_ptr;
36                 delete this->_count;
37             }
38         }
39 
40         this->_ptr = ptr._ptr;
41         this->_count = ptr._count;
42         (*this->_count)++;
43         return *this;
44     }
45 
46     T& operator*() {
47         assert(this->_ptr == nullptr);
48         return *(this->_ptr);
49 
50     }
51 
52     T* operator->() {
53         assert(this->_ptr == nullptr);
54         return this->_ptr;
55     }
56 
57     ~SmartPointer() {
58         (*this->_count)--;
59         if (*this->_count == 0) {
60             delete this->_ptr;
61             delete this->_count;
62         }
63     }
64 
65     size_t use_count(){
66         return *this->_count;
67     }
68 };
69 
70 int main() {
71     {
72         SmartPointer<int> sp(new int(10));
73         SmartPointer<int> sp2(sp);
74         SmartPointer<int> sp3(new int(20));
75         sp2 = sp3;
76         std::cout << sp.use_count() << std::endl;
77         std::cout << sp3.use_count() << std::endl;
78     }
79     //delete operator
80 }

编译与链接对C&C++程序员既熟悉又陌生，熟悉在于每份代码都要经历编译与链接过程，陌生在于大部分人并不会刻意关注编译与链接的原理。本文通过开发过程中碰到的四个典型问题来探索64位linux下C++编译&链接的那些事。

以下是正文

编译原理

将如下最简单的C++程序（main.cpp）编译成可执行目标程序，实际上可以分为四个步骤:预处理、编译、汇编、链接，可以通过

g++ main.cpp –v看到详细的过程，不过现在编译器已经把预处理和编译过程合并。

预处理：g++ -E main.cpp -o main.ii，-E表示只进行预处理。预处理主要是处理各种宏展开；添加行号和文件标识符，为编译器产生调试信息提供便利；删除注释；保留编译器用到的编译器指令等。

编译：g++ -S main.ii –o main.s，-S表示只编译。编译是在预处理文件基础上经过一系列词法分析、语法分析及优化后生成汇编代码。

汇编：g++ -c main.s –o main.o。汇编是将汇编代码转化为机器可以执行的指令。

链接：g++ main.o。链接生成可执行程序，之所以需要链接是因为我们代码不可能像main.cpp这么简单，现代软件动则成百上千万行，如果写在一个main.cpp既不利于分工合作，也无法维护，因此通常是由一堆cpp文件组成，编译器分别编译每个cpp，这些cpp里会引用别的模块中的函数或全局变量，在编译单个cpp的时候是没法知道它们的准确地址，因此在编译结束后，需要链接器将各种还没有准确地址的符号（函数、变量等）设置为正确的值，这样组装在一起就可以形成一个完整的可执行程序。

问题一：头文件遮挡

在编译过程中最诡异的问题莫过于头文件遮挡，如下代码中main.cpp包含头文件common.h，真正想用的头文件是图中最右边那个包含name

成员的文件（所在目录为./include），但在编译过程中中间的common.h（所在目录为./include1）抢先被发现，导致编译器报错：Test结构没有name成员，对程序员来讲，自己明明定义了name成员，居然说没有name这个成员，如果第一次碰到这种情况可能会怀疑人生。应对这种诡异的问题，我们可以用-E参数看下编译器预处理后的输出，如下图。

预处理文件格式如下：# linenum filename flag，表示之后的内容是从文件名为filaname的文件中第linenum行展开的，flag的取值可以是1,2,3,4，可以是用空格分开的多值，1表示接下来要展开一个新文件；2表示一个文件展开完毕；3表示接下来内容来自一个系统头文件；4表示接下来的内容应该看做是extern C形式引入的。

从展开后的输出我们可以清楚地看到Test结构确实没有定义name这个成员，并且Test这个结构是在./include1中的common.h中定义的，到此真相大白，编译器压根就没用我们定义的Test结构，而是被别的同名头文件截胡了。我们可以通过调整-I或者在头文件中带上部分路径更详细制定头文件位置来解决。

目标文件：

编译链接最终会生成各种目标文件，Linux下目标文件格式为ELF（Executable Linkable Format），详细定义见/usr/include/elf.h头文件，常见的目标文件有：可重定位目标文件，也即.o结尾的目标文件，当然静态库也归为此类；可执行文件，比如默认编译出的a.out文件；共享目标文件.so；核心转储文件，也就是core dump后产出的文件。Linux文件格式可以通过file命令查看。

一个典型的ELF文件格式如下图所示，文件有两种视角：编译视角，以section头部表为核心组织程序；运行视角，程序头部表以segment为核心组织程序。这么做主要是为了节约存储，很多细碎的section在运行时由于对齐要求会导致很大的内存浪费，运行时通常会将权限类似的section组织成segment一起加载。

通过命令objdump和readelf可以查看ELF文件的内容。

对可重定位目标文件常见的section有:

符号解析：

链接器会为对外部符号的引用修改为正确的被引用符号的地址，当无法为引用的外部符号找到对应的定义时，链接器会报undefined reference to XXXX的错误。另外一种情况是，找到了多个符号的定义，这种情况链接器有一套规则。在描述规则前需要了解强符号和弱符号的概念，简单讲函数和已初始化的全局变量是强符号，未初始化的全局变量是弱符号。

针对符号的多重定义链接器处理规则如下（作者在gcc 7.3.0上貌似规则2,3都按1处理）：

1. 不允许多个强符号定义，链接器会报告重复定义貌似的错误

2. 如果一个强符号和多个弱符号同名，则选择强符号

3. 如果符号在所有目标文件中都为弱符号，那么选择占用空间最大的一个

有了这些基础，我们先来看一下静态链接过程：

1. 链接器从左到右按照命令行出现顺序扫描目标文件和静态库

2. 链接器维护一个目标文件的集合E，一个未解析符号集合U，以及E中已定义的符号集合D，初始状态E、U、D都为空

3. 对命令行上每个文件f，链接器会判断f是否是一个目标文件还是静态库，如果是目标文件，则f加入到E，f中未定义的符号加入到U中，已定义符号加入到D中，继续下一文件

4. 如果是静态库，链接器尝试到静态库目标文件中匹配U中未定义的符号，如果m中匹配U中的一个符号，那么m就和上步中文件f一样处理，对每个成员文件都依次处理，直到U、D无变化，不包含在E中的成员文件简单丢弃

5. 所有输入文件处理完后，如果U中还有符号，则出错，否则链接正常，输出可执行文件

问题二：静态库顺序

如下图所示，main.cpp依赖liba.a，liba.a又依赖libb.a，根据静态链接算法，如果用g++ main.cpp liba.a libb.a的顺序能正常链接，因为解析liba.a时未定义符号FunB会加入到上述算法的U中，然后在libb.a中找到定义，如果用g++ main.cpp libb.a liba.a的顺序编译，则无法找到FunB的定义，因为根据静态链接算法，在解析libb.a的时候U为空，所以不需要做任何解析，简单抛弃libb.a，但在解析liba.a的时候又发现FunB没有定义，导致U最终不为空，链接错误，因此在做静态链接时，需要特别注意库的顺序安排，引用别的库的静态库需要放在前面，碰到链接很多库的时候，可能需要做一些库的调整，从而使依赖关系更清晰。

动态链接：

之前大部分内容都是静态链接相关，但静态链接有很多不足：不利于更新，只要有一个库有变动，都需要重新编译；不利于共享，每个可执行程序都单独保留一份，对内存和磁盘是极大的浪费。

要生成动态链接库需要用到参数“-shared -fPIC”表示要生成位置无关PIC（Position Independent Code）的共享目标文件。对静态链接，在生成可执行目标文件时整个链接过程就完成了，但要想实现动态链接的效果，就需要把程序按照模块拆分成相对独立的部分，在程序运行时将他们链接成一个完整的程序，同时为了实现代码在不同程序间共享要保证代码是和位置无关的（因为共享目标文件在每个程序中被加载的虚拟地址都不一样，要保证它不管被加载在哪都能工作），而为了实现位置无关又依赖一个前提：数据段和代码段的距离总是保持不变。

由于不管在内存中如何加载一个目标模块，数据段和代码段间的距离是不变的，编译器在数据段前面引入了一个全局偏移表GOT（Global Offset Table），被引用的全局变量或者函数在GOT中都有一条记录，同时编译器为GOT中每个条目生成一个重定位记录，因为数据段是可以修改的，动态链接器在加载时会重定位GOT中的每个条目，这样就实现了PIC。

大体原理基本就这样，但具体实现时，对函数的处理和全局变量有所不同。由于大型程序函数成千上万，而程序很可能只会用到其中的一小部分，因此没必要加载的时候把所有的函数都做重定位，只有在用到的时候才对地址做修订，为此编译器引入了过程链接表PLT（Procedure Linkage Table）来实现延时绑定。PLT在代码段中，它指向了GOT中函数对应的地址，第一次调用时候，GOT存放的不是函数的实际地址，而是PLT跳转到GOT代码的后一条指令地址，这样第一次通过PLT跳转到GOT，然后通过GOT又调回到PLT的下一条指令，相当于什么也没做，紧接着PLT后面的代码会将动态链接需要的参数入栈，然后调用动态链接器修正GOT中的地址，从这以后，PLT中代码跳转到GOT的地址就是函数真正的地址，从而实现了所谓的延时绑定。

对共享目标文件而言，有几个需要关注的section：

有了以上基础后，我们看一下动态链接的过程：

1. 装载过程中程序执行会跳转到动态链接器

2. 动态链接器自举通过GOT、.dynamic信息完成自身的重定位工作

3. 装载共享目标文件：将可执行文件和链接器本身符号合并入全局符号表，依次广度优先遍历共享目标文件，它们的符号表会不断合并到全局符号表中，如果多个共享对象有相同的符号，则优先载入的共享目标文件会屏蔽掉后面的符号

4. 重定位和初始化

问题三：全局符号介入

动态链接过程中最关键的第3步可以看到，当多个共享目标文件中包含一个相同的符号，那么会导致先被加载的符号占住全局符号表，后续共享目标文件中相同符号被忽略。当我们代码中没有很好的处理命名的话，会导致非常奇怪的错误，幸运的话立刻core dump，不幸的话直到程序运行很久以后才莫名其妙的core dump，甚至永远不会core dump但是结果不正确。

如下图所示，main.cpp中会用到两个动态库libadd.so，libadd1.so的符号，我们把重点

放在Add函数的处理上，当我们以g++ main.cpp libadd.so libadd1.so编译时，程序输出“Add in add lib”说明Add是用的libadd.so中的符号（add.cpp），当我们以g++ main.cpp libadd1.so libadd.so编译时，程序输出“Add in add1 lib”说明Add是用的libadd1.so中的符号，这时候问题就大了，调用方main.cpp中认为Add只有两个参数，而add1.cpp中认为Add有三个参数，程序中如果有这样的代码，可以预见很可能造成巨大的混乱。具体符号解析我们可以通过LD_DEBUG=all ./a.out来观察Add的解析过程，如下图所示：左边是对应libadd.so在编译时放在前面的情况，Add绑定在libadd.so中，右边对应libadd1.so放前面的情况，Add绑定在libadd1.so中。

运行时加载动态库：

有了动态链接和共享目标文件的加持，Linux提供了一种更加灵活的模块加载方式：通过提供dlopen，dlsym，dlclose，dlerror几个API，可以实现在运行的时候动态加载模块，从而实现插件的功能。

如下代码演示了动态加载Add函数的过程，add.cpp按照正常编译“g++ -fPIC –shared –o libadd.so add.cpp”成libadd.so，main.cpp通过“g++ main.cpp -ldl”编译为a.out。main.cpp中首先通过dlopen接口取得一个句柄void *handle，然后通过dlsym从句柄中查找符号Add，找到后将其转化为Add函数，然后就可以按照正常的函数使用，最后dlclose关闭句柄，期间有任何错误可以通过dlerror来获取。

问题四：静态全局变量与动态库导致double free

在全面了解了动态链接相关知识后，我们来看一个静态全局变量和动态库纠结在一起引发的问题，代码如下，foo.cpp中有一个静态全局对象foo_，foo.cpp会编译成一个libfoo.a，bar.cpp依赖libfoo.a库，它本身会编译成libbar.so，main.cpp既依赖于libfoo.a又依赖libbar.so。

编译的makefile如下：

运行a.out会导致double free的错误。这是由于在一个位置上调用了两次析构函数造成的。之所以会这样是因为链接的时候先链接的静态库，将foo_的符号解析为静态库中的全局变量，当动态链接libbar.so时，由于全局已经有符号foo_，因此根据全局符号介入，动态库中对foo_的引用会指向静态库中版本，导致最后在同一个对象上析构了两次。

解决办法如下：

1. 不使用全局对象

2. 编译时候调换库的顺序，动态库放在前面，这样全局只会有一个foo_对象

3. 全部使用动态库

4. 通过编译器参数来控制符号的可见性。

总结：

通过四个编译链接中碰到的问题，基本把编译链接的这些事覆盖了一遍，有了这些基础，在日常工作中应对一般的编译链接问题应该可以做到游刃有余。由于篇幅有限，文章省略了大量的细节，主要集中在大的框架原理性梳理，如果想进一步深挖相关的细节，可参与相关参考文献，以及阅读elf.h相关的头文件。