如何利用Kubernetes榨干JAVA(2)

“在过去的几年中，我们发现Java确实不适合高密度，低资源的环境，” Sharples告诉The Next Platform。“ Java JDK运行时是一项了不起的工程壮举，它完成了一些令人难以置信的事情，但是它确实是为这样一个时代设计的：您拥有一台专用计算机，一个拥有大量内存的大型多处理器系统，而Java的工作是最大限度地利用机器必须提供的所有资源，并为大型银行应用程序提供最佳的吞吐量。”
Java应用程序的一个显著问题是，如果开发人员允许JVM为诸如垃圾收集器和堆大小之类的功能设置默认值，则在容器内运行的Java进程将不会表现出预期的行为。这恰恰是因为Java早于Linux内核功能（例如cgroup），这些功能控制着容器内部进程使用的资源，因此它只是查看整个系统可用的资源，并相应地为其分配内存和CPU。
Java 10的发布部分解决了该特定问题，因此JVM能够识别cgroup设置的约束，从而可以直接为容器中的Java应用程序定义内存和CPU约束。
但这不是唯一的问题。如前所述，容器背后的学说是容器是短暂的。实例在需要时产生，它们运行一小段时间，然后被杀死，如果再次需要其功能，则新实例将取代它们。这几乎与Java设计的运行方式截然相反。
“我们现在生活在一个世界上，您很幸运能得到一台物理机的一小部分，您将在虚拟机中得到一个容器，您可能只是获得足够的CPU和内存来一次执行您的功能。您的应用程序组件，微服务或功能本质上是短暂的-它们来来往往，每小时可能重新部署数十次。Java所做的许多令人惊奇的事情是它可以随时间进行的概要分析和调整，以优化代码执行。再说一次，如果您的代码一次运行数月甚至数年，那完全有道理。如果您只能按功能运行，那么您将无能力执行任何操作。” Sharples解释说。
这意味着Java代码将浪费宝贵的时间在分布式容器部署模型中多余的事情上。Java应用程序或应用程序服务器所做的事情是在启动时花费大量时间来进行类加载和加载配置数据，并且每次应用程序启动时都会这样做。
“所有这些开始变成真正的开销，您要做的所有初始化工作。因此，我们基本上将所有这些东西都拿走了，并把它推到了编译时间，所以只完成了一次。您可以将其完全脱离生产环境。这确实大大缩短了启动时间，这对于可以经常部署的微服务很重要。从按下部署按钮到能够处理第一个请求之间的时间是至关重要的–如果您必须等待30秒或一分钟才能开始处理请求，那真是浪费。