2022年9月

前几日早上打开邮箱收到一封监控报警邮件:某某 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环境配置

首先是 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  ...


项目创建
通过命令行在当前路径下创建一个名为 Comics 的项目

scrapy startproject Comics
创建完成后,当前目录下出现对应的项目文件夹,可以看到生成的Comics文件结构为:










|____Comics| |______init__.py| |______pycache__| |____items.py| |____pipelines.py| |____settings.py| |____spiders| | |______init__.py| | |______pycache__|____scrapy.cfg
Ps. 打印当前文件结构命令为:

find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
每个文件对应的具体功能可查阅官方文档,本篇实现对这些文件涉及不多,所以按下不表。

1、创建Spider类

创建一个用来实现具体爬取功能的类,我们所有的处理实现都会在这个类中进行,它必须为 scrapy.Spider 的子类。
在 Comics/spiders 文件路径下创建 comics.py 文件。
comics.py 的具体实现:















#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.Spider的子类,其中的name属性为该爬虫的唯一标识,作为scrapy爬取命令的参数。其他方法的属性后续再解释。
2、运行
创建好自定义的类后,切换到Comics路径下,运行命令,启动爬虫任务开始爬取网页。

scrapy crawl comics
打印的结果为爬虫运行过程中的信息,和目标爬取网页的html源码。







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
我们主要的关注点在于页面中间的漫画列表,列表下方有显示页数的控件。如下图所示
图片
爬虫的主要任务是爬取列表中每一部漫画的图片,爬取完当前页后,进入下一页漫画列表继续爬取漫画,依次不断循环直至所有漫画爬取完毕。
起始地址的url我们放在了start_requests函数的urls数组中。其中start_requests是重载了父类的方法,爬虫任务开始时会执行到这个方法。
start_requests方法中主要的执行在这一行代码:请求指定的url,请求完成后调用对应的回调函数self.parse

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);
start_urls是框架中提供的属性,为一个包含目标网页url的数组,设置了start_urls的值后,不需要重载start_requests方法,爬虫也会依次爬取start_urls中的地址,并在请求完成后自动调用parse作为回调方法。
不过为了在过程中方便调式其它的回调函数,demo中还是使用了前一种实现方式。

2、爬取漫画url

从起始网页开始,首先我们要爬取到每一部漫画的url。

当前页漫画列表

起始页为漫画列表的第一页,我们要从当前页中提取出所需信息,动过实现回调parse方法。
在开头导入BeautifulSoup

from bs4 import BeautifulSoup
请求返回的html源码用来给BeautifulSoup初始化。



def parse(self, response):    content = response.body;    soup = BeautifulSoup(content, "html5lib")
初始化指定了html5lib解释器,若没安装这里会报错。
BeautifulSoup初始化时若不提供指定解释器,则会自动使用自认为匹配的最佳解释器,这里有个坑,对于目标网页的源码使用默认最佳解释器为lxml,此时解析出的结果会有问题,而导致无法进行接下来的数据提取。所以当发现有时候提取结果又问题时,打印soup看看是否正确。
查看html源码可知,页面中显示漫画列表的部分为类名为listconul标签,通过listcon类能唯一确认对应的标签
图片
提取包含漫画列表的标签

listcon_tag = soup.find('ul', class_='listcon')
上面的find方法意为寻找classlistconul标签,返回的是对应标签的所有内容。
在列表标签中查找所有拥有href属性的a标签,这些a标签即为每部漫画对应的信息。

com_a_list = listcon_tag.find_all('a', attrs={'href': True})
然后将每部漫画的href属性合成完整能访问的url地址,保存在一个数组中。





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)
此时comics_url_list数组即包含当前页每部漫画的url。

3、下一页列表

看到列表下方的选择页控件,我们可以通过这个地方来获取到下一页的url。
图片
获取选择页标签中,所有包含href属性的a标签


page_tag = soup.find('ul', class_='pagelist')page_a_list = page_tag.find_all('a', attrs={'href': True})
这部分源码如下图,可看到,所有的a标签中,倒数第一个代表末页的url,倒数第二个代表下一页的url,因此,我们可以通过取page_a_list数组中倒数第二个元素来获取到下一页的url。
图片
但这里需要注意的是,若当前为最后一页时,不需要再取下一页。那么如何判断当前页是否是最后一页呢?
可以通过select控件来判断。通过源码可以判断,当前页对应的option标签会具有selected属性,下图为当前页为第一页
图片
下图为当前页为最后一页
图片
通过当前页数与最后一页页数做对比,若相同则说明当前页为最后一页。







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)
当前不为最后一页,则继续对下一页做相同的处理,请求依然通过回调parse方法做处理






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、爬取漫画图片

parse方法中提取到当前页的所有漫画url时,就可以开始对每部漫画进行处理。
在获取到comics_url_list数组的下方加上下面代码:


for url in comics_url_list:    yield scrapy.Request(url=url, callback=self.comics_parse)
对每部漫画的url进行请求,回调处理方法为self.comics_parsecomics_parse方法用来处理每部漫画,下面为具体实现。

5、当前页图片

首相将请求返回的源码构造一个BeautifulSoup,和前面基本一致



def comics_parse(self, response):    content = response.body;    soup = BeautifulSoup(content, "html5lib")
提取选择页控件标签,页面显示和源码如下所示
图片
图片
提取classpagelistul标签

page_list_tag = soup.find('ul', class_='pagelist')
查看源码可以看到当前页的li标签的class属性thisclass,以此获取到当前页页数


current_li = page_list_tag.find('li', class_='thisclass')page_num = current_li.a.string
当前页图片的标签和对应源码
图片
图片
获取当前页图片的url,以及漫画的标题。漫画标题之后用来作为存储对应漫画的文件夹名称。





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

6、保存到本地
当提取到图片url时,便可通过url请求图片并保存到本地

self.save_img(page_num, title, img_url)
定义了一个专门用来保存图片的方法save_img,具体完整实现如下




















































# 先导入库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)
函数主要用到3个参数,当前图片的页数,漫画的名称,图片的url。
图片会保存在以漫画名称命名的文件夹中,若不存在对应文件夹,则创建一个,一般在获取第一张图时需要自主创建一个文件夹。
document为本地指定的文件夹,可自定义。
每张图片以页数.jpg的格式命名,若本地已存在同名图片则不再进行重新下载,一般用在反复开始任务的情况下进行判断以避免对已存在图片进行重复请求。
请求返回的图片数据是被压缩过的,可以通过response.info().get('Content-Encoding')的类型来进行判断。压缩过的图片要先经过zlib.decompress解压再保存到本地,否则图片打不开。
大体实现思路如上,代码中也附上注释了。

7、下一页图片

和在漫画列表界面中的处理方式类似,在漫画页面中我们也需要不断获取下一页的图片,不断的遍历直至最后一页。
图片
当下一页标签的href属性为#时为漫画的最后一页







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)

8、运行结果
大体的实现基本完成,运行起来,可以看到控制台打印情况
图片
本地文件夹保存到的图片
图片
scrapy框架运行的时候使用了多线程,能够看到多部漫画是同时进行爬取的。
目标网站资源服务器感觉比较慢,会经常出现请求超时的情况。跑的时候请耐心等待。

最后
本文介绍的只是scrapy框架非常基本的用法,还有各种很细节的特性配置。
如使用FilesPipelineImagesPipeline来保存下载的文件或者图片。
框架本身自带了个XPath类用来对网页信息进行提取,这个的效率要比BeautifulSoup高,也可以通过专门的item类将爬取的数据结果保存作为一个类返回。具体请查阅官网。


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相关的头文件。


C++ 中的虚函数的作用主要是实现了多态的机制。关于多态,简而言之就是用父类型别的指针指向其子类的实例,然后通过父类的指针调用实际子类的成员函数。这种技术可以让父类的指针有“多种形态”,这是一种泛型技术。

虚函数表

每个含有虚函数的类都有一个虚函数表(Virtual Table)来实现的。简称为V-Table。C++的编译器应该是保证虚函数表的指针存在于对象实例中最前面的位置(这是为了保证取到虚函数表的有最高的性能——如果有多层继承或是多重继承的情况下)。这意味着我们通过对象实例的地址得到这张虚函数表,然后就可以遍历其中函数指针,并调用相应的函数。

1、 每一个类都有虚函数列表。

2、 虚表可以继承,如果子类没有重写虚函数,那么子类虚表中仍然会有该函数的地址,只不过这个地址指向的是基类的虚函数实现。如果基类3个虚函数,那么基类的虚表中就有三项(虚函数地址),派生类也会有虚表,至少有三项,如果重写了相应的虚函数,那么虚表中的地址就会改变,指向自身的虚函数实现。如果派生类有自己的虚函数,那么虚表中就会添加该项。

3、 派生类的虚表中虚函数地址的排列顺序和基类的虚表中虚函数地址排列顺序相同,子类独有的虚函数放在后面。

当定义一个有虚函数类的对象时,对象的第一块的内存空间就是一个指向虚函数列表的指针。

在这举个例子

假设我们有这样的一个类:

图片

由于例程的操作环境是64位系统,所以用long*强转。其中(long*)(&b)就是虚函数表地址,(long*)*(long*)(&b)就是第一个函数地址,代码运行结果如下:

图片

在程序中取出对象b的地址,根据对象的布局可以得出就是虚表的地址,根据这个地址可以把虚表的第一个内存单元的内容取出,然后强制转换成一个函数指针,利用这个函数指针来访问虚函数。又因为虚表是连续的,利用每次+1可以来访问下一个内存单元。

如果对代码不理解的话,可以看这幅图就会懂了

注意:虚函数表在最后会有一个结束标志,为1说明还有虚表,为0表示没有虚表了 。(编译器不同,结束标志可能存在差异)图片

下面,将分别具体说明“无虚函数覆盖”和“有虚函数覆盖”时的虚函数表的情况。

(一)无虚函数覆盖

没有任何的继承,虚函数表如下图

图片图片

根据示意图,编写的代码如下图所示:

图片

和上一个程序一样,根据取出虚表里面的地址强制转换成函数指针,同样,利用虚表的连续性,每次指针+1调用对应的虚函数。可以得出虚函数按照其声明顺序存放于虚函数表中的,子类自己的虚函数是排在父类虚函数之后的。运行结果如下图

图片


(二)一般继承(有虚函数覆盖)

如果子类中有虚函数重载了父类的虚函数,会是一个什么样子?假设,我们有下面这样的一个继承关系。如图所示:

图片

在这个类的设计中,只覆盖了父类的一个函数:f()。那么,对于派生类的实例,其虚函数表会是下面的一个样子:

图片

从表中可以看到下面几点,

1)覆盖的f()函数被放到了虚表中原来父类虚函数的位置。

2)没有被覆盖的函数依旧。

这样就会出现虚调用

Base *b = new Derive();

b->f();

由b所指的内存中的虚函数表的f()的位置已经被Derive::f()函数地址所取代,于是在实际调用发生时,是Derive::f()被调用了。这就实现了多态。下面我们用一个示例代码来看一下

图片

运行结果如下,确实如我们以上分析的那样,由b所指的内存中的虚函数表的f()的位置已经被Derive::f()函数地址所取代:

图片

(三)多重继承(无虚函数覆盖)

下面我们再看看多重继承的情况

图片

对于子类实例中的虚函数表,是下面这个样子:

图片

从图上我们可以看到

1)每个父类都有自己的虚表。

2) 子类的成员函数被放到了第一个父类的表中。(所谓的第一个父类是按照声明顺序来判断的)

这样做就是为了解决不同的父类类型的指针指向同一个子类实例,而能够调用到实际的函数。

下面我们根据上图来实现一下

图片图片

运行结果如下:

图片

在这个程序中,子类有多个父类,因此从每个父类都继承了一个虚表,因此会有3个虚表,根据代码和运行结果会发现,排列的顺序和继承的顺序一样,子类自己的虚函数排在第一个虚表的后面。程序中没有改写虚函数 ,因此没有覆盖。同时主函数中应用的是一个二重指针,利用二维数组取每个虚函数地址。

(四)多重继承(有虚函数覆盖)

下面我们再来看看,如果发生虚函数覆盖的情况。

下图中,我们在子类中覆盖了父类的f()函数。

图片

子类虚函数列表如图所示

图片

三个父类虚函数表中的f()的位置被替换成了子类的函数指针。这样,我们就可以任一静态类型的父类来指向子类,并调用子类的f()了。

子类虚函数列表访问代码如下:

图片图片

程序运行结果如下所示:

图片

本程序中,子类重写了f函数,把所有父类里面的f函数都屏蔽了。在虚表中父类f函数的位置全部换成了子类f函数的地址。因此在输出时父类的f函数没有了,全部是子类f函数的输出。