敩科炼技堂
工作历经华为，阿里和字节跳动。
资深研发专家
获得徽章 0
不论Win还是Linux，都存在静态库和动态库。
软件开发过程中：
1）静态库是直接编译链接到二进制中的
2）动态库的链接是在运行时进行的，即运行时进行链接，并将符号导入到进程地址空间的
但是，很多开发者仍然有一点是不知道的：
动态库在系统内存中，是各个进程共享的。
换句话说，在各个进程中，动态库是位于相同的系统物理内存地址中，但却不同（不一定相同）的进程虚拟地址中。
这也是为什么Linux的动态库，以so后缀命名（shared object）。
但是，这是如何做到的呢？
当然是要依赖一个外部的链接器来做。
比如，在Linux中，应用程序启动时，需要动态链接的进程，通常代理给ldd（链接器）来查找相应的so，并完成so文件到进程的虚拟地址空间的内存映射的。如此，so既然是文件，就可以在相同的物理内存中被各个进程所共享。使用动态库链接的方式，通过共享物理的内存映射方式，从而大大节省了众多只读库对系统物理内存的消耗。
软件开发过程中：
1）静态库是直接编译链接到二进制中的
2）动态库的链接是在运行时进行的，即运行时进行链接，并将符号导入到进程地址空间的
但是，很多开发者仍然有一点是不知道的：
动态库在系统内存中，是各个进程共享的。
换句话说，在各个进程中，动态库是位于相同的系统物理内存地址中，但却不同（不一定相同）的进程虚拟地址中。
这也是为什么Linux的动态库，以so后缀命名（shared object）。
但是，这是如何做到的呢？
当然是要依赖一个外部的链接器来做。
比如，在Linux中，应用程序启动时，需要动态链接的进程，通常代理给ldd（链接器）来查找相应的so，并完成so文件到进程的虚拟地址空间的内存映射的。如此，so既然是文件，就可以在相同的物理内存中被各个进程所共享。使用动态库链接的方式，通过共享物理的内存映射方式，从而大大节省了众多只读库对系统物理内存的消耗。
展开
评论
2
写过跨Linuxicon和Windows平台系统软件（C/C++）的研发工作者，一定深感到其中的痛苦。尽管在一些网络协议（如：TCP/IP）上是相同的，但编程模型、以及编译器上的细微差别就让人头疼万分。
犇叔略举几个点：
1）事件通知模型：众所周知，Linux有基于事件的用户态中断机制，通俗来说就是select/poll/epoll的用户态和内核态事件通知模型。要在Windows系统上找出对等的机制，可不太容易。
2）GNU C编译器和MSVC编译器：总有一些出乎你意料的编译器行为，犇叔建议一定要写好单模块的ut用例。
3）原子操作icon和内存语义：找到匹配的原子操作，不是那么困难。但仍然要注意其中语义差别，包括内存可见性和内存序问题（这一点，犇叔下半年写一个相关专题）。
4）并发：多线程icon和多进程在这两个平台上的差别非常大，要特别留意Linux下的“惊群”唤醒，以及Windows下iocp的内部机制，性能表现非常大。
今天，总体而言，Windows作为数据中心的常驻服务端已经少之又少。但包括客户端（如docker)，以及众多优势领域，仍然绕不开Windows平台的支持，譬如图形图像渲染、远程桌面等。就Windows APIicon来说，犇叔认为其设计非常优秀，相比Linux系统调用和GNU C lib库的而言，不管是文档还是统一的风格，对程序员icon更友好。缺点是：“API数量真的非常庞大”。想来，这也是微软要做一个上层统一框架的直接原因吧。
#创意代码大赏#
犇叔略举几个点：
1）事件通知模型：众所周知，Linux有基于事件的用户态中断机制，通俗来说就是select/poll/epoll的用户态和内核态事件通知模型。要在Windows系统上找出对等的机制，可不太容易。
2）GNU C编译器和MSVC编译器：总有一些出乎你意料的编译器行为，犇叔建议一定要写好单模块的ut用例。
3）原子操作icon和内存语义：找到匹配的原子操作，不是那么困难。但仍然要注意其中语义差别，包括内存可见性和内存序问题（这一点，犇叔下半年写一个相关专题）。
4）并发：多线程icon和多进程在这两个平台上的差别非常大，要特别留意Linux下的“惊群”唤醒，以及Windows下iocp的内部机制，性能表现非常大。
今天，总体而言，Windows作为数据中心的常驻服务端已经少之又少。但包括客户端（如docker)，以及众多优势领域，仍然绕不开Windows平台的支持，譬如图形图像渲染、远程桌面等。就Windows APIicon来说，犇叔认为其设计非常优秀，相比Linux系统调用和GNU C lib库的而言，不管是文档还是统一的风格，对程序员icon更友好。缺点是：“API数量真的非常庞大”。想来，这也是微软要做一个上层统一框架的直接原因吧。
#创意代码大赏#
展开
评论
点赞