使用共享库并不总是比使用静态库好吗？
is using shared libraries is not always better than using a static libraries?
假设我们有多个 .c 文件，如 a.c、b.c、c.c、d.c ...等，然后我们创建一个共享库 sharedlib.so 基于这些文件和 main.c 只使用一个函数让我们 functionb() 在 b.c.
根据我对共享库的理解，每个共享库都有一个 .text 部分，这个 .text 部分包含其成员文件 a.c, [=11] 中的所有函数说明=]、c.c、d.c ...等。所以即使 main.c 只使用一个函数，共享库也会被加载到内存中，因此整个 .text 部分都在内存中，并且 sharedlib.so 的 .text 部分包含一个许多 main.c 不使用的功能。
我上面的理解对吗？ （我理解使用共享库的好处，因为与静态库相比，内存中只有一个副本。所以一般来说，最好使用共享库）只是想仔细检查一下使用共享库是否会导致将不必要的东西复制到内存。
您更愿意使用共享库来节省系统内存。
静态库效率很高，但对您的内存消耗很大。
使用共享库会显着降低二进制文件的大小。
此外，您将拥有共享库的单个副本，而不是每个静态 link.
的一个副本。
希望对您有所帮助:)
是的，但是...如果您的 应用程序是唯一 系统上使用该库的应用程序，您应该使用静态库。
共享库节省内存，因为它们是共享；可以组织它们，以便对于大型服务器上的每个共享库，即使 100 个不同用户的 10 个不同的 exe 正在使用它，ram 中也只存在 一个 副本。这是不可能的静态库；如果您有 10 个不同的 exe 使用同一个库，那么您可能在 RAM 中有 10 个副本。
gcc 确实会将来自多个目标文件的文本部分连接成一个文本部分，并且加载程序确实会将整个文本部分“加载到内存中”。但是，您不应该假设本例中的“内存”指的是物理内存。整个库将占用链接它的进程的一部分虚拟地址 space，但不需要占用相同数量的物理内存。理想情况下，只有与使用的函数对应的特定虚拟内存页面才会映射到物理内存。
此外，在某种程度上物理内存页可以映射到多个进程的虚拟地址space，如果这些进程使用相同的库。但是，这种页面共享有很多复杂性。
然而，这个问题是真实存在的，如果仅仅是膨胀的共享对象可能导致大量内存分页的话。有许多与优化共享对象的内存行为相关的技巧，例如在源代码中将相互调用的函数放在一起，因此它们很可能最终位于同一内存页中。
假设我们有多个 .c 文件，如 a.c、b.c、c.c、d.c ...等，然后我们创建一个共享库 sharedlib.so 基于这些文件和 main.c 只使用一个函数让我们 functionb() 在 b.c.
根据我对共享库的理解，每个共享库都有一个 .text 部分，这个 .text 部分包含其成员文件 a.c, [=11] 中的所有函数说明=]、c.c、d.c ...等。所以即使 main.c 只使用一个函数，共享库也会被加载到内存中，因此整个 .text 部分都在内存中，并且 sharedlib.so 的 .text 部分包含一个许多 main.c 不使用的功能。
我上面的理解对吗？ （我理解使用共享库的好处，因为与静态库相比，内存中只有一个副本。所以一般来说，最好使用共享库）只是想仔细检查一下使用共享库是否会导致将不必要的东西复制到内存。
您更愿意使用共享库来节省系统内存。 静态库效率很高，但对您的内存消耗很大。
使用共享库会显着降低二进制文件的大小。 此外，您将拥有共享库的单个副本，而不是每个静态 link.
的一个副本。希望对您有所帮助:)
是的，但是...如果您的 应用程序是唯一 系统上使用该库的应用程序，您应该使用静态库。
共享库节省内存，因为它们是共享；可以组织它们，以便对于大型服务器上的每个共享库，即使 100 个不同用户的 10 个不同的 exe 正在使用它，ram 中也只存在 一个 副本。这是不可能的静态库；如果您有 10 个不同的 exe 使用同一个库，那么您可能在 RAM 中有 10 个副本。
gcc 确实会将来自多个目标文件的文本部分连接成一个文本部分，并且加载程序确实会将整个文本部分“加载到内存中”。但是，您不应该假设本例中的“内存”指的是物理内存。整个库将占用链接它的进程的一部分虚拟地址 space，但不需要占用相同数量的物理内存。理想情况下，只有与使用的函数对应的特定虚拟内存页面才会映射到物理内存。
此外，在某种程度上物理内存页可以映射到多个进程的虚拟地址space，如果这些进程使用相同的库。但是，这种页面共享有很多复杂性。
然而，这个问题是真实存在的，如果仅仅是膨胀的共享对象可能导致大量内存分页的话。有许多与优化共享对象的内存行为相关的技巧，例如在源代码中将相互调用的函数放在一起，因此它们很可能最终位于同一内存页中。