百度+腾讯+华为+美团，面经问题总结

史蒂夫和斯凯

　　根据牛客网百度+腾讯+华为+美团，已定TX中提到的面试问题总结而成。

1. CPU使用率过高 怎么看在程序中CPU 使用过高的地方在哪
　　

top、ps　　

2. tcp滑动窗口
　　转自 TCP 滑动窗口（发送窗口和接收窗口）
　　TCP 滑动窗口（发送窗口和接收窗口）
　　TCP的滑动窗口主要有两个作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。
　　TCP的Window是一个16bit位字段，它代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16-1=65535个字节。
　　另外在TCP的选项字段中还包含了一个TCP窗口扩大因子，option-kind为3，option-length为3个字节，option-data取值范围0-14。窗口扩大因子用来扩大TCP窗口，可把原来16bit的窗口，扩大为31bit。
　　滑动窗口基本原理
　　1）对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口（中间两部分）。
　　当收到接收方新的ACK对于发送窗口中后续字节的确认是，窗口滑动，滑动原理如下图。
　　当收到ACK=36时窗口滑动。
　　2）对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。“已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。其中“未接收准备接收”称之为接收窗口。
　　发送窗口与接收窗口关系
　　TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。
　　滑动窗口实现面向流的可靠性
　　最基本的传输可靠性来源于“确认重传”机制。
　　TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
　　发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
　　接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
　　滑动窗口的流控特性
　　TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。
　　应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。
　　========================END========================

3.构造函数定义成虚函数可以吗？ 析构函数可以定义成虚函数吗？

• 可以，但是没有动态绑定的效果，父类构造函数中调用的仍然是父类版本的函数，子类中调用 的仍然是子类版本的函数
  

　　链接：https://www.nowcoder.com/questionTerminal/677ebdf5533943868ff7c8b8c1377f46?from=14pdf
　　
来源：牛客网

• 基类通常都应该定义一个虚析构函数，以确保执行正确的析构函数版本。
  

　　在C++中我们可以使用基类cBase的指针pBase（或引用）指向一个子类cChild，当pBase指针被撤销的时候，会先调用子类的析构函数，再调用基类的构造函数。如果不是virtual，那么撤销pBase指针时，将不会调用子类的析构函数，造成了内存泄露。

4.static, Const的用法
　　作者：Xi Yang
　　
链接：https://www.zhihu.com/question/29307292/answer/68695290
　　
来源：知乎
　　
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
　　define和那两个都不一样，它属于宏，是预处理器的一部分。预处理是在编译之前的一道，简单地进行字符串替换。它不按照语言的语法，而是直观自己的语法。你define里面写的东西会被简单粗暴地塞进去：
　　

define FuckTwice fuck fuck　　

　　
FuckTwice;
　　

　　会得到：fuck fuck;
　　
编译器会感觉你写了一个变量，名字是fuck，类型是fuck。const是单词constant的简写，字面意思是常数、常量。用于变量修饰，表明这个变量不能被修改；用于指针修饰，表明指针的指向物不能被修改；用于方法修饰，表明这个方法不会对对象造成改变。const int foo = 1;
　　

foo = 2; // compile time error　　

　　
const int* ptr = &foo;
　　
*ptr = 3 // compile time error
　　

　　
int fuck = 0;
　　
ptr = &fuck; // this is OK
　　
*ptr = 123; // compile time error
　　

　　
struct FooBar
　　
{
　　int member;
　　int MyMethod(int value) const
　　{
　　member = value; // compile time error
　　}
　　
};
　　

　　static很讨厌，有三个个完全不同的含义：用在全局变量，表明这个变量在每个编译单元有独自的实例：// foo.h
　　

static int a = 123;　　
// foo.cpp
　　
#include "foo.h"
　　
int foo_func() { return a++; }
　　
// bar.cpp
　　
#include "foo.h"
　　
int bar_func() { return a++; }
　　
如果你分别编译foo.cpp和bar.cpp，再把它们链接在一起，全局变量a会有两份，那两个函数会操纵不一样的a实例。用在函数里的局部变量，表明它的生存周期其实是全局变量，但仅在函数内可见：int get_global_id()
　　
{
　　static int seed = 0;
　　return seed++;
　　
}
　　

　　每次访问这个函数的时候，会获得不同的int值。那个=0的操作仅在第一次访问时执行，其实是初始化而不是赋值。用在类成员，表明成员或者方法是类的，而不是对象实例的。
　　

struct Foo　　
{
　　int a = 0;
　　static int aaa = 0;
　　static int bbb() { return 123456; }
　　
};
　　

　　每个Foo实例会只含有一个int a。bbb方法通过Foo::bbb()调用。

5. 内存泄漏怎么处理，举例句柄泄漏

内存泄露
　　其实内存泄漏的原因可以概括为：调用了malloc/new等内存申请的操作，但缺少了对应的free/delete，总之就是，malloc/new比free/delete的数量多。我们在编程时需要注意这点，保证每个malloc都有对应的free，每个new都有对应的deleted！！！平时要养成这样一个好的习惯。
　　要避免内存泄漏可以总结为以下几点：
　　程序员要养成良好习惯，保证malloc/new和free/delete匹配；
　　
检测内存泄漏的关键原理就是，检查malloc/new和free/delete是否匹配，一些工具也就是这个原理。要做到这点，就是利用宏或者钩子，在用户程序与运行库之间加了一层，用于记录内存分配情况。

1. 如何发现内存泄漏
　　有些简单的内存泄漏问题可以从在代码的检查阶段确定。还有些泄漏比较严重的，即在很短的时间内导致程序或系统崩溃，或者系统报告没有足够内存，也比较容易发现。最困难的就是泄漏比较缓慢，需要观测几天、几周甚至几个月才能看到明显异常现象。那么如何在比较短的时间内检测出有没有潜在的内存泄漏问题呢？实际上不同的系统都带有内存监视工具，我们可以从监视工具收集一段时间内的堆栈内存信息，观测增长趋势，来确定是否有内存泄漏。在 Linux 平台可以用 ps 命令，来监视内存的使用，比如下面的命令 (观测指定进程的VSZ值)：
　　
ps -aux

2 静态代码分析工具
　　代码静态扫描和分析的工具比较多，比如 splint, PC-LINT, BEAM 等。因为 BEAM 支持的平台比较多，这以 BEAM 为例，做个简单介绍，其它有类似的处理过程。
　　
BEAM 可以检测四类问题: 没有初始化的变量；废弃的空指针；内存泄漏；冗余计算。而且支持的平台比较多。
　　
可以把 BEAM 看作一个 C/C++ 编译器，按下面的命令进行编译 (前面两个命令是设置编译器环境变量)：
　　

./beam-3.4.2/bin/beam_configure  --c gcc　　
./beam-3.4.2/bin/beam_configure  --cpp g++
　　
./beam-3.4.2/bin/beam_compile  --beam::compiler=compiler_cpp_config.tcl  -cpp code2.cpp
　　

　　从下面的编译报告中，我们可以看到这段程序中有三个错误:”内存泄漏”；“变量未初始化”；“ 空指针操作”
　　

"code2.cpp", line 10: warning: variable "b" was set but never used　　int b, c;
　　^
　　

　　
BEAM_VERSION=3.4.2
　　
BEAM_ROOT=/home/hanzb/memdetect
　　
BEAM_DIRECTORY_WRITE_INNOCENTS=
　　
BEAM_DIRECTORY_WRITE_ERRORS=
　　

　　
-- ERROR23(heap_memory)     /*memory leak*/     >>>ERROR23_LeakTest_7b00071dc5cbb458
　　
"code2.cpp", line 24: memory leak
　　
ONE POSSIBLE PATH LEADING TO THE ERROR:
　　"code2.cpp", line 22: allocating using `operator new[]' (this memory will not be freed)
　　"code2.cpp", line 22: assigning into `Logmsg'
　　"code2.cpp", line 24: deallocating `Logmsg' because exiting its scope
　　(losing last pointer to the memory)
　　

3. 动态运行检测
　　实时检测工具主要有 valgrind, Rational purify 等。
　　
在 Linux 系统中，使用 Purify 需要重新编译程序。通常的做法是修改 Makefile 中的编译器变量。下面是用来编译本文中程序的 Makefile：
　　
CC=purify gcc
　　
首先运行 Purify 安装目录下的 purifyplus_setup.sh 来设置环境变量，然后运行 make 重新编译程序。
　　
./purifyplus_setup.sh
　　
下面给出编译一个代码文件的示例，源代码文件命名为 test3.cpp. 用 purify 和 g++ 的编译命令如下，‘-g’是编译时加上调试信息。
　　
purify g++ -g test3.cpp –o test
　　
运行编译生成的可执行文件 test，就可以得到图1，可以定位出内存泄漏的具体位置。
　　
./test
　　


句柄泄露

　　这里以linux环境中的一个socket连接中的句柄泄漏的例子来说明句柄泄漏的情况：有三个应用程序A，B，C，它们运行在不同的机器上，它们之间通过socket接口进行通信。其中A和B之间通信，A是服务端；B是客户端，B和C之间通信，B是服务端，C是客户端。它们之间的通信都是TCP的。现在，B要给A发送数据，B在发送前，如果发现和A之间的连接断开，就会去重连，在重连的时候，B并没有close已经断开连接的socket>
　　上面就是一个socket句柄泄漏的例子。解决上面的问题的具体方法是：在B每次重连A的时候，调用系统提供的close()函数，把已经断开连接的socket的socket>　　不管是内存也好，还是句柄也好，都是可以统称为资源的，对资源的使用，要求都是统一的，就是要“有借有还，再借不难”。我们要谨记“文明”使用操作系统提供给我们的资源，力争写出更加“和谐”的程序来！

6. 内存的分配方式有几种？
　　1． 从静态存储区分配：此时的内存在程序编译的时候已经分配好，并且在程序的整个运行期间都存在。全局变量，static变量等在此存储。
　　
2． 在栈区分配：相关代码执行时创建，执行结束时被自动释放。局部变量在此存储。栈内存分配运算内置于处理器的指令集中，效率高，但容量有限。
　　
3． 在堆区分配：动态分配内存。用new/malloc时开辟，delete/free时释放。生存期由用户指定，灵活。但有内存泄露等问题。

7. dll加载到内存位于哪个区, C++ 内存管理问题

　　所谓动态链接，就是把一些经常会共用的代码（静态链接的OBJ程序库）制作成DLL档，当可执行文件调用到DLL档内的函数时，Windows操作系統才会把DLL档加载存储器内，DLL档本身的结构就是可执行文件，当程序需求函数才进行链接。通过动态链接方式，存储器浪费的情形将可大幅降低。静态链接库则是直接链接到可执行文件。
　　
静态链接库在链接时，编译器会将.obj文件和.LIB文件组织成一个.exe文件，程序运行时，将全部数据加载到内存。如果程序体积较大，功能较为复杂，那么加载到内存中的时间就会比较长。
　　
使用GNU的工具我们如何在Linux下创建自己的程序函数库?一个“程序函数库”简单的说就是一个文件包含了一些编译好的代码和数据，这些编译好的代码和数据可以在事后供其他的程序使用。程序函数库可以使整个程序更加模块化，更容易重新编译，而且更方便升级。
　　程序函数库可分为3种类型：静态函数库（static libraries）、共享函数库（shared libraries）、动态加载函数库（dynamically loaded libraries）：
　　1、静态函数库，是在程序执行前就加入到目标程序中去了；
　　2、共享函数库，则是在程序启动的时候加载到程序中，它可以被不同的程序共享；动态加载函数库则可以在程序运行的任何时候动态的加载。
　　3、动态函数库，并非另外一种库函数格式，区别是动态加载函数库是如何被程序员使用的。

• 　　静态函数库
  　　
  静态函数库实际上就是简单的一个普通的目标文件的集合，一般来说习惯用“.a”作为文件的后缀。可以用ar这个程序来产生静态函数库文件。Ar是archiver的缩写。静态函数库现在已经不在像以前用得那么多了，主要是共享函数库与之相比较有很多的优势的原因。慢慢地，大家都喜欢使用共享函数库了。不过，在一些场所静态函数库仍然在使用，一来是保持一些与以前某些程序的兼容，二来它描述起来也比较简单。
  　　
  
  静态库函数允许程序员把程序link起来而不用重新编译代码，节省了重新编译代码的时间。不过，在今天这么快速的计算机面前，一般的程序的重新编译也花费不了多少时间，所以这个优势已经不是像它以前那么明显了。静态函数库对开发者来说还是很有用的，例如你想把自己提供的函数给别人使用，但是又想对函数的源代码进行保密，你就可以给别人提供一个静态函数库文件。理论上说，使用ELF格式的静态库函数生成的代码可以比使用共享函数库（或者动态函数库）的程序运行速度上快一些，大概1－5％。
  

　　创建一个静态函数库文件，或者往一个已经存在地静态函数库文件添加新的目标代码，可以用下面的命令：
　　

    ar rcs my_library.a file1.o file2.o 　　

　　这个例子中是把目标代码file1.o和file2.o加入到my_library.a这个函数库文件中，如果my_library.a不存在则创建一个新的文件。在用ar命令创建静态库函数的时候，还有其他一些可以选择的参数，可以参加ar的使用帮助。这里不再赘述。
　　一旦你创建了一个静态函数库，你可以使用它了。你可以把它作为你编译和连接过程中的一部分用来生成你的可执行代码。如果你用gcc来编译产生可执行代码的话，你可以用“-l”参数来指定这个库函数。你也可以用ld来做，使用它的“-l”和“-L”参数选项。具体用法可以参考info:gcc。

• 　　共享函数库
  　　
  共享函数库中的函数是在当一个可执行程序在启动的时候被加载。如果一个共享函数库正常安装，所有的程序在重新运行的时候都可以自动加载最新的函数库中的函数。对于Linux系统还有更多可以实现的功能：
  　　
  1、升级了函数库但是仍然允许程序使用老版本的函数库。
  　　
  2、当执行某个特定程序的时候可以覆盖某个特定的库或者库中指定的函数。
  　　
  3、可以在库函数被使用的过程中修改这些函数库。
  
  
• 　　动态加载的函数库Dynamically Loaded (DL) Libraries
  
  

　　动态加载的函数库Dynamically loaded (DL) libraries是一类函数库，它可以在程序运行过程中的任何时间加载。它们特别适合在函数中加载一些模块和plugin扩展模块的场合，因为它可以在当程序需要某个plugin模块时才动态的加载。例如，Pluggable Authentication Modules(PAM)系统就是用动态加载函数库来使得管理员可以配置和重新配置身份验证信息。
　　Linux系统下，DL函数库与其他函数库在格式上没有特殊的区别，我们前面提到过，它们创建的时候是标准的object格式。主要的区别就是这些函数库不是在程序链接的时候或者启动的时候加载，而是通过一个API来打开一个函数库，寻找符号表，处理错误和关闭函数库。通常C语言环境下，需要包含这个头文件。
　　
Linux中使用的函数和Solaris中一样，都是dlpoen（） API。当然不是所有的平台都使用同样的接口，例如HP-UX使用shl_load()机制，而Windows平台用另外的其他的调用接口。如果你的目的是使得你的代码有很强的移植性，你应该使用一些wrapping函数库，这样的wrapping函数库隐藏不同的平台的接口区别。一种方法是使用glibc函数库中的对动态加载模块的支持，它使用一些潜在的动态加载函数库界面使得它们可以夸平台使用。具体可以参考http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html. 另外一个方法是使用libltdl，是GNU libtool的一部分，可以进一步参考CORBA相关资料。

内存管理
　　在Win32中，DLL文件按照片段（sections）进行组织。每个片段有它自己的属性，如可写或是只读、可执行（代码）或者不可执行（数据）等等。这些section可分为两种，一个是与绝对地址寻址无关的，所以能被多进程公用；另一个是与绝对地址寻址有关的，这个就必须由每个进程有自己的副本专用。sections的这种二分类，在编译DLL时就已经由编译器、链接器给标注好了。所以在装入DLL时，装入器知道哪些sections在内存物理地址空间只需要有一份，供多个进程共用（映射到各个进程的内存逻辑地址空间，所以逻辑地址可以不同）； 哪些sections必须是进程使用自己的专用副本。
　　
具体说，DLL装入时需考虑下述情形：

• 局部变量——每个线程都有自己的栈，DLL内部的局部变量随所在函数被执行而在各自线程的调用栈上开辟存储空间。
  
• 全局变量
  

• DLL内部定义的全局变量
  
• const全局变量——放入const节中，多进程共享；
  
• 非const全局变量——放入各个进程各自专用的data节中。即DLL装入时各个进程复制一份自己专用的DLL的data节。但是，对于一个进程内的多个线程并发访问这种进程空间全局变量，仍然存在线程安全问题。例如，在一个COM的DLL加载入一个进程的空间后，该进程的多个线程可能会并发访问该COM库的COM对象。为此，Windows与COM引入了线程“套间”(apartment)技术。一个进程内，应用程序与加载的各个DLL分属于不同的Module，如果DLL使用所在Module的全局变量，例如动态链接MFC的regular dll在访问自己的MFC全局变量时，应该明确声明。
  
• 访问DLL以外定义的全局变量——使用间址技术，在DLL的data节中用一个指针数据类型的内存空间来保存一个外部全局变量的地址。
  

• 函数调用
  

• 调用DLL内部定义的函数。这不是问题。
  
• 调用DLL外部定义的函数。例如，DLL内部调用一个外部函数foo()。这个foo函数在进程1中可能实现为“四舍五入”，在进程2中实现为“下取整”。所以调用外部函数是各个进程私用的事情。解决办法是使用间址技术，在data节中用一个“函数指针”数据类型的内存空间来保存这种外部函数的入口地址。
  

• 跳转指令
  

• DLL内部跳转，不是问题
  
• 跳转到DLL外部，解决同上述3.2　　
  DLL代码段通常被使用这个DLL的所有进程所共享。如果代码段所占据的物理内存被收回，它的内容就会被放弃，后面如果需要的话就直接从DLL文件重新加载。
  　　
  与代码段不同，DLL的数据段通常是私有的；也就是说，每个使用DLL的进程都有自己的DLL数据副本。作为选择，数据段可以设置为共享，允许通过这个共享内存区域进行进程间通信。但是，因为用户权限不能应用到这个共享DLL内存，这将产生一个安全漏洞；也就是一个进程能够破坏共享数据，这将导致其它的共享进程异常。例如，一个使用访客账号的进程将可能通过这种方式破坏其它运行在特权账号的进程。这是在DLL中避免使用共享片段的一个重要原因。
  　　
  当DLL被如UPX这样一个可执行的packer压缩时，它的所有代码段都标记为可以读写并且是非共享的。可以读写的代码段，类似于私有数据段，是每个进程私有的并且被页面文件备份。这样，压缩DLL将同时增加内存和磁盘空间消耗，所以共享DLL应当避免使用压缩DLL。
  
  

8. 静态链接与动态链接的区别
　　通常情况下，对函数库的链接是放在编译时期（compile time）完成的。所有相关的对象文件 （object file）与牵涉到的函数库（library）被链接合成一个可执行文件 （executable file）。程序 在运行 时，与函数库再无瓜葛，因为所有需要的函数已拷贝到自己门下。所以这些函数库被成为静态库（static libaray），通常文件 名为“libxxx.a”的形式。
　　其实，我们也可以把对一些库函数的链接载入推迟到程序运行的时期（runtime）。这就是如雷贯耳的动态链接库（dynamic link library）技术。
　　一 例子详解
　　
文件目录树如下:

• libtest/
  
• |-- myjob.c
  
• |-- myjob.h
  
• |-- test.c　　
  静态库
  　　
  A.做成静态库 libmyjob.a
  
  
• $ gcc -c myjob.c -o myjob.o
  
• $ ar -c -r -s libmyjob.a myjob.o　　
  B.链接
  
  
• $ gcc test.o libmyjob.a -o test　　
  C.引用库情况（无所要信息）
  
  
• $ ldd test
  
• linux-gate.so.1 => (0xffffe000)
  
• libc.so.6 => /lib/libc.so.6 (0xb7e29000)
  
• /lib/ld-linux.so.2 (0xb7f6e000)　　
  动态库
  　　
  A.做成动态库 libmyjob.so
  
  
• $ gcc -Wall –fPIC -c myjob.c -o myjob.o　　
  
  
  
• $ gcc -shared -o libmyjob.so myjob.o　　
  -shared: 该选项指定生成动态连接库（让连接器生成T 类型的导出符号表，有时候也生成弱连接 W 类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件。
  　　
  -fPIC： 表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。
  　　
  -L.： 表示要连接的库在当前目录中。
  　　
  LD_LIBRARY_PATH： 这个环境变量指示动态连接器可以装载动态库的路径。
  　　
  B.链接
  　　
  链接方法I ，拷贝到系统库里再链接，让 gcc 自己查找：
  
  
• $ cp libmyjob.so /usr/lib
  
• $ gcc -o test test.o -lmyjob　　
  这里我们可以看到了 -lmyjob 选项， -l[lib_name] 指定库名，他会主动搜索。 lib[lib_name].so 这个搜索的路径可以通过 gcc --print-search-dirs 来查找。
  　　
  链接方法II ，手动指定库路径
  
  
• $ gcc -o test test.o -lmyjob -B /path/to/lib　　
  -B 选项就添加 /path/to/lib 到 gcc 搜索的路径之中。这样链接没有问题但是方法 II 中手动链接好的程序在 执行 时候仍旧需要指定库路径（ 链接和执行是分开的 ）。需要添加系统变量 LD_LIBRARY_PATH :
  
  
• $ export LD_LIBRARY_PATH=/path/to/lib　　
  这个时候再来检测一下test 程序的库链接状况 ( 方法 I 情况 )
  
  
• $ ldd test
  
• linux-gate.so.1 => (0xffffe000)
  
• libmyjob.so => /usr/lib/ libmyjob .so (0xb7f58000)
  
• libc.so.6 => /lib/libc.so.6 (0xb7e28000)
  
• /lib/ld-linux.so.2 (0xb7f6f000)　　
  是不是比静态链接的程序多了一个 libmyjob.so? 这就是静态与动态的最大区别，静态情况下，它把库直接加载到程序里，而在动态链接的时候，它只是保留接口，将动态库与程序代码独立。这样就可以提高代码的可复用度，和降低程序的耦合度。
  　　
  另外，运行时，要保证主程序能找到动态库，所以动态库一般发布到系统目录中，要么就在跟主程序相对很固定的路径里，这样不管主程序在本机何时何地跑，都能找得到动态库。而静态库只作用于链接时，运行主程序时静态库文件没存在意义了。
  
  

　　二 静态库和动态库的区别

• 静态函数库　　
  这类库的名字一般是 libxxx.a ；利用静态函数库编译成的文件比较大，因为整个函数库的所有数据都会被整合进目标代码中，他的优点就显而易见了，即编译后的执行程序不需要外部的函数库支持，因为所有使用的函数都已经被编译进去了。当然这也会成为他的缺点，因为 如果静态函数库改变了，那么你的程序必须重新编译 。
  
  
• 动态函数库　　
  这类库的名字一般是 libxxx.so ;相对于静态函数库，动态函数库在编译的时候并没有被编译进目标代码中，你的程序执行到相关函数时才调用该函数库里的相应函数，因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序，而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库。 动态函数库的改变并不影响你的程序，所以动态函数库的升级比较方便。
  
  

9. 同步，异步区别，使用场合
　　同步、异步、阻塞、非阻塞这几个概念在并发编程和架构设计中用的比较多，这里阐释一下他们之间的区别。
　　同步：多个任务或事件必须顺序执行，前一个任务没执行完，后一行任务就不能进行。
　　
实现：常见的顺序编程, 串行执行
　　
场景：B/S架构的HTTP请求-响应模式、OA流程。
　　异步：多个任务或事情可以并行执行，任意一个任务的执行不会阻塞另外一个任务的执行。异步调用完成后，通过通知或回调将结果传递给接收者。异步常用于操作时间比较耗时的场合，为了不block当前的工作流程，而采用异步。
　　
实现：新建一个线程，或把任务放到消息队列中由消费者处理、并行处理
　　
场景：发短信、写信、写邮件、发微信，网上办电信业务（比如申请信用卡）、node.js、ajax。
　　同步和异步着重点在于多个任务的执行过程中，一个任务的执行是否会导致整个流程的阻塞。
　　阻塞：当调 用没有结果返回时，线程处于挂起状态（线程进入非可执行状态，在这个状态下，cpu不会给线程分配时间片，即线程暂停运行），等待结果返回。
　　
场景：排队进火车检票口、排队办业务。
　　非阻塞：当调用没有结果返回时，马上返回一个信息，告知条件不满足，不会一直在那儿等待。
　　
场景： 网上买火车票时，没订到票时，使用定时监控软件去看有没有火车票。

select、poll、epoll简介
　　epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现
　　
select：
　　select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：
　　1、 单个进程可监视的fd数量被限制，即能监听端口的大小有限。
　　

一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.　　

　　2、 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：
　　
当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
　　3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
　　poll：
　　poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
　　它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：
　　1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。 2、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
　　epoll:
　　
epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知
　　epoll的优点：

• 没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）；
  
• 效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；　　
  即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
  
  
• 内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
  

　　select、poll、epoll 区别总结：
　　

　　

　　
总结：
　　综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。

• 　　表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
  
  
• 　　select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
  
  

10. https结构

客户端请求消息
　　客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
　　


服务器响应消息
　　HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
　　

　　实例
　　
下面实例是一点典型的使用GET来传递数据的实例：
　　
客户端请求：
　　

GET /hello.txt HTTP/1.1　　
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
　　
Host: www.example.com
　　
Accept-Language: en, mi
　　

　　服务端响应:
　　

HTTP/1.1 200 OK　　
Date: Mon, 27 Jul 2009 12:28:53 GMT
　　
Server: Apache
　　
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
　　
ETag: "34aa387-d-1568eb00"
　　
Accept-Ranges: bytes
　　
Content-Length: 51
　　
Vary: Accept-Encoding
　　
Content-Type: text/plain
　　

　　输出结果：
　　
Hello World! My payload includes a trailing CRLF.

11. tcp 三次握手 四次挥手 两次呢？2MSL？
　　答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
　　
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
　　
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
　　
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。
　　MSL是Maximum Segment Lifetime,译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
　　
2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

12. 怎么保证可靠性传输? tcp重传

　　

　　


13. hadoop了解吗，谷歌的fs知道吗
　　略~

14. gdb

15. 设计模式
　　常见设计模式

• 写一个单例类。　　
  答：单例模式主要作用是保证在 Java 应用程序中，一个类只有一个实例存在。下面给出两种不同形式的单例：
  
  

　　第一种形式：饿汉式单例

　　public>　　
private Singleton(){}
　　
private static Singleton instance = new Singleton();
　　
public static Singleton getInstance(){
　　
return instance;
　　
}
　　
}
　　
第二种形式：懒汉式单例

　　public>　　
private static Singleton instance = null;
　　
private Singleton() {}
　　
public static synchronized Singleton getInstance(){
　　
if (instance==null) instance＝newSingleton();
　　
return instance;
　　
}
　　
}
　　
单例的特点：外界无法通过构造器来创建对象，该类必须提供一个静态方法向外界提供该类的唯一实例。
　　【补充】用 Java 进行服务器端编程时，使用单例模式的机会还是很多的，服务器上的资源都是很宝贵的，对于那些无状态的对象其实都可以单例化或者静态化（在内存中仅有唯一拷贝），如果使用了 Spring 这样的框架来进行对象托管，Spring 的 IoC 容器在默认情况下对所有托管对象都是进行了单例化处理的。

• 说说你所熟悉或听说过的设计模式以及你对设计模式的看法。　　
  答：在 GoF 的《Design Patterns: Elements of Reusable Object-Oriented Software》中给出了三类（创建型[对类的实例化过程的抽象化]、结构型[描述如何将类或对象结合在一起形成更大的结构]、行为型[对在不同的对象之间划分责任和算法的抽象化]）共 23 种设计模式，包括：Abstract Factory（抽象工厂模式），Builder（建造者模式），Factory Method（工厂方法模式），Prototype（原始模型模式），Singleton（单例模式）；Facade（门面模式），Adapter（适配器模式），Bridge（桥梁模式），Composite（合成模式），Decorator（装饰模式），Flyweight（享元模式），Proxy（代理模式）；Command（命令模式），Interpreter（解释器模式），Visitor（访问者模式），Iterator（迭代子模式），Mediator（调停者模式），Memento（备忘录模式），Observer（观察者模式），State（状态模式），Strategy（策略模式），Template Method（模板方法模式）， Chain Of Responsibility（责任链模式）。
  
  

　　所谓设计模式，就是一套被反复使用的代码设计经验的总结（情境中一个问题经过证实的一个解决方案）。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。

• 你在开发中都用到了那些设计模式？用在什么场合？　　
  答：面试被问到关于设计模式的知识时，可以拣最常用的作答，例如：
  
  

　　1)工厂模式：工厂类可以根据条件生成不同的子类实例，这些子类有一个公共的抽象父类并且实现了相同的方法，但是这些方法针对不同的数据进行了不同的操作（多态方法）。当得到子类的实例后，开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。
　　2)代理模式：给一个对象提供一个代理对象，并由代理对象控制原对象的引用。实际开发中，按照使用目的的不同，代理可以分为：远程代理、虚拟代理、保护代理、Cache 代理、防火墙代理、同步化代理、智能引用代理。
　　3)适配器模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起使用的类能够一起工作。
　　4)模板方法模式：提供一个抽象类，将部分逻辑以具体方法或构造器的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法（多态实现），从而实现不同的业务逻辑。
　　除此之外，还可以讲讲上面提到的门面模式、桥梁模式、单例模式、装潢模式（Collections 工具类里面的 synchronizedXXX 方法把一个线程不安全的容器变成线程安全容器就是对装潢模式的应用，而 Java IO 里面的过滤流（有的翻译成处理流）也是应用装潢模式的经典例子）等，反正原则就是拣自己最熟悉的用得最多的作答，以免言多必失。

• 编程题: 写一个Singleton出来
  　　
  Singleton 模式主要作用是保证在 Java 应用程序中，一个类>
  

　　第一种形式: 定义一个类，它的构造函数为 private的，它有一个 static 的 private 的该类变量，在类初始化时实例话，通过一个 public 的 getInstance 方法获取对它的引用,继而调用其中的方法。

　　public>　　
private Singleton(){}
　　
　　 //在自己内部定义自己一个实例，是不是很奇怪？
　　
　　 //注意这是private 只供内部调用
　　
　　 private static Singleton instance = new Singleton();
　　
　　 //这里提供了一个供外部访问本class的静态方法，可以直接访问　　
　　
　　 public static Singleton getInstance() {
　　
　　　　 return instance; 　　
　　
　　 }
　　
}
　　
第二种形式:

　　
public>　　
　　private static Singleton instance = null;
　　
　　public static synchronized Singleton getInstance() {
　　
　　//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次　　　 　
　　
　　//使用时生成实例，提高了效率！
　　
　　if (instance==null)
　　
　　　　instance＝new Singleton();
　　
return instance; 　　}
　　
}
　　
其他形式:
　　定义一个类，它的构造函数为 private 的，所有方法为 static 的。
　　一般认为第一种形式要更加安全些