到目前为止，我一直认为容器技术(例如：docker)提供了所需的隔离和操作系统级虚拟化。容器中运行的应用程序受到命名空间、cgroups、apparmour/selinux等功能的限制，他们无法确定自己所处的主机环境。但这种理解似乎不是100%正确的。
与wiki一样，操作系统级别的虚拟化
OS级虚拟化是一种操作系统范例内核允许存在多个隔离的用户空间实例。这样的实例称为容器(LXC、Solaris容器、Docker)，分区(Solaris容器)、虚拟专用服务器(OpenVZ)，分区、虚拟环境(VE)、虚拟内核(DragonFlyBSD)，或监狱(FreeBSD监狱或chroot监狱)，1可能看起来像真实的从运行在计算机中的程序的角度来看。A.在普通操作系统上运行的计算机程序可以看到所有资源(连接的设备、文件和文件夹、网络共享、CPU功率、可量化的硬件能力)然而，在容器内运行的程序只能看到容器的分配给容器的内容和设备
从上面的引用来看，它似乎只添加了隔离和抽象，而不像虚拟化。
由于Java团队必须向JVM添加容器支持，所以它不直接查看主机环境，而是将ITSELF限制在docker提供的隔离/抽象中
参考文献：
- Java(在JDK8更新131之前)应用程序在docker容器中运行CPU/Memory问题？给出了一个很好的答案，解释了JVM对linux容器的支持
Linux容器支持首先出现在JDK10中，然后移植到8u191，
- 如何防止Java超过容器内存限制
这是否意味着在容器环境中运行的C程序可以绕过限制并访问/读取主机环境的详细信息当然，当它试图(即使用这些信息)做任何超出容器允许做的事情时，容器引擎可能会扼杀容器本身的进程。
因此，如果我正在开发一个请求/查询主机资源(如CPU/MEM/Devices等)的C/C++应用程序，我是否有责任通过添加容器支持，使该应用程序在容器环境中按预期运行。
尽管我怀疑这是否是一个流行的答案，但我的观点是，必须为可能在容器环境中运行的应用程序提供明确指定资源限制的方法。依赖系统查询的信息是错误的。
容器不是完全的虚拟化环境，通常不会完全隐藏底层平台。虽然容器可能在网络、文件系统和用户级别与主机隔离，但这并不意味着它们是真正独立的。我遇到的一个典型问题是，容器无法获得自己对系统平均负载的贡献——只能获得主机的平均负载。
没有完全虚拟化并不意味着主机不能强制执行限制——它通常可以，而且确实可以。但这意味着容器不能很容易地找到它们，而不是以一种健壮的、平台中立的方式。
容器可以使用各种启发式方法。例如，它可能能够解析/proc/self/cgroup。这可能会提供有用的信息，也可能不会，具体取决于实施情况。只有当主机使用控制组时，这种方法才会提供有用的信息——大多数当前的实现都是这样，但这并不意味着它是强制性的。
目前有许多不同的容器框架在使用，而且这个数字可能还会增加。很难预测将来必须使用什么方法，以使应用程序容器具有可验证性。我认为，最好为用户提供一种控制限制的方法，而不是为你开发的每一个软件都有一个持续的维护任务。
在容器环境中，构建可以运行多个副本的小型互连容器通常效果更好。然后，您可以根据工作负载调整环境的大小，而不是根据其环境调整工作负载的大小。
一个更容易思考的例子是处理异步任务的工作进程。在非容器环境中，典型的设置是询问主机有多少内核，然后启动那么多线程。这并不能很好地转化为容器，正是因为你引用了各种各样的问题。相反，通常最好让您的工作进程是单线程的，但随后根据工作需要启动尽可能多的副本。
特别是如果您在云环境中运行Kubernetes，那么这样做确实有一些好处。在Kubernetes部署中，您可以指定容器的replicas:的数量，并动态更改，这样您就完全不受硬件配置的约束。您可以使用一个名为horizontalpod autoscaler的Kubernetes片段，根据队列长度自动设置部署计数。当当前集群的工作负载太大时，您可以使用另一个名为集群自动缩放器的Kubernetes片段来自动请求更多的云计算节点。这是一个基本假设，即单个容器(Kubernetes Pods)是小型的、无状态的，并且在任何硬件设置上都表现相同。
您引用的JVM内存限制问题也面临类似的问题。JVM的默认行为是将25%的系统内存用于堆，但现在的问题是，面对每个容器的资源限制，如何决定有多少内存？不过，大多数应用程序运行时都没有像这样依赖于系统的硬内存限制；您谈论的是C程序，malloc()将正常工作，直到达到内核强制的(物理或cgroup)内存限制。
因此，如果我正在开发一个C/C++应用程序，它请求/查询主机资源，如CPU/MEM/Devices。。。
。。。在Docker这样的隔离系统中运行它是不合适的。直接在主机上运行。