使用共享库并不总是比使用静态库更好吗？答案

【问题标题】：is using shared libraries is not always better than using a static libraries?使用共享库并不总是比使用静态库更好吗？
【发布时间】：2020-09-03 07:04:06
【问题描述】：

假设我们有多个 .c 文件，如 a.c、b.c、c.c、d.c ...等，然后我们根据这些文件和 main.c 创建一个共享库 sharedlib.so只使用一个函数让我们functionb() in b.c。

根据我对共享库的理解，每个共享库都有一个.text 部分，这个.text 部分包含其成员文件a.c、b.c、c.c、d.c 中的所有函数指令...ETC。所以即使main.c只使用一个函数，共享库也会被加载到内存中，因此整个.text部分都在内存中，而sharedlib.so的.text部分包含很多main.c没有的函数不要使用。

我的上述理解正确吗？（我了解使用共享库的好处，因为与静态库相比，内存中只有一个副本。所以一般来说，使用共享库更好）只是想仔细检查一下使用共享库是否会导致将不必要的东西复制到记忆。

【问题讨论】：

无论您使用多少共享库，都会加载整个共享库。使用情况取决于您是否完全控制共享库。如果您期待一个特定版本并且加载了不同的版本，它可能会或可能不会工作。有时，因为调用丢失或参数不同。

标签： c linux gcc dll dynamic-linking

【解决方案1】：

是的，但是...如果您的应用程序是系统上使用该库的唯一应用程序，那么您应该使用静态库。

共享库节省内存，因为它们是共享的；可以组织它们，以便对于大型服务器上的每个共享库，只有一个副本存在于 ram 中，即使 100 个不同用户的 10 个不同 exe 正在使用它。这是不可能的静态库；如果你有 10 个不同的 exe 使用同一个库，那么你可能在 RAM 中有 10 个副本。

【讨论】：

【解决方案2】：

您更喜欢使用共享库来节省系统内存。静态库效率很高，但对您的内存消耗很大。

使用共享库会显着减小二进制文件的大小。此外，您将拥有一个共享库的副本，而不是每个静态链接一个副本。

希望对您有所帮助:)

【讨论】：

【解决方案3】：

gcc 确实会将来自多个目标文件的文本部分连接到单个文本部分中，并且加载器确实会将整个文本部分“加载到内存中”。但是，您不应该假设在这种情况下“内存”是指物理内存。整个库将占用链接它的进程的一部分虚拟地址空间，但它不需要占用相同数量的物理内存。理想情况下，只有与所使用的功能相对应的特定虚拟内存页面才会映射到物理内存。

另外，在某种程度上，物理内存页可以映射到多个进程的虚拟地址空间，如果这些进程使用同一个库的话。但是，这种页面共享存在许多复杂性。

尽管如此，这个问题是真实存在的，即使只是到一个膨胀的共享对象会导致大量内存分页的程度。有许多与优化共享对象的内存行为相关的技巧，例如在源代码中将相互调用的函数放在一起，因此它们很可能最终在同一个内存页面中。

【讨论】：