我的问题更多是关于Java线程的。但是对于操作系统级别的线程来说，它可能也更通用。
JAVA特定：ThreadPool Tuning Size的意义是什么。 （公式）？带有容器的冲击性能及其在发动机罩下的行为。 （我想我可以理解cpu设置，但不能理解cpu共享，我知道什么是cpu共享，只是不了解线程在这里的行为。）
所以我是一篇有关java in containers的文章，（我在CloudFoundary上运行应用程序时观察到了），3和enhancements，它们是JDK 10中引入的，用于检测容器限制。
在上述文章中：
让我们简短地了解一下JVM如何根据运行的节点上的可用处理器/内核数量进行调整。实际上，实际上有许多参数是根据核心数初始化的。 因此，如果GC线程，JIT线程等的默认默认值是可用的“核心”总数。
现在，如果
number_of_cpus（）将基于cpu_shares（）/ 1024计算
然后在CPU份额为512的情况下进行计算。此计算将得出0。（然后，我假定该值将舍入为1 ??）。 这样如何工作？
答案 0 :(得分：3)
是的，它将四舍五入为 1 。
该实现在./hotspot/os/linux/osContainer_linux.cpp下，基本上看起来像这样：
share_count = ceilf((float)share / (float)PER_CPU_SHARES);
其中PER_CPU_SHARES = 1024和共享是您的示例512。此函数将产生1。
我不确定您的编辑是否能正确理解您，但是当在同一操作系统上运行的多个容器尝试使用100％的CPU时，cpu-share很重要。假设您有3个容器，一个包含1024，另外两个包含512 cpu份额。当其中的三个全部尝试获得100％的CPU时间时，就会发生这种情况：50％的时间将流向拥有1024份额的容器，其他将获得每个25%；但是同样，这仅在CPU处于100%时。
现在再次阅读该JEP-它仅影响JIT / GC线程-不影响您的应用程序线程；您仍然可以创建尽可能多的线程，因此无论该文章如何建议-它仍然有效，为容器或无容器。