背景
最近遇到一个有意思的事情，java应用运行在阿里云的ack集群中，某一天有个应用启动突然发现阿里云上的agent都没有注册了，于是开始排查原因。
排查过程
我们的应用是java应用，jdk版本是Open-jdk8，阿里云agent是直接注入到容器中的，因此会将agent启动参数自动注入到 JAVA_TOOL_OPTIONS 环境变量中，当应用启动时会自动带上agent启动参数。
agent没注册，首先检查应用的启动日志，发现应用是启动成功的，tomcat端口都是正常的。仔细观察日志，发现了问题。由于agent 启动参数是注入到 JAVA_TOOL_OPTIONS 中的，通常jvm 在启动的时候会优先加载 JAVA_TOOL_OPTIONS，日志中会出现 Picked up JAVA_TOOL_OPTIONS 的字样，如下图所示，但是问题现场却没有这一行和agent相关的启动日志，说明 jvm 启动的时候并没有加载 JAVA_TOOL_OPTIONS。
我们开始怀疑是 agent启动参数 的问题，以为是agent在容器重建时没有将启动参数注入到环境变量中。但是通过环境变量一看，发现 JAVA_TOOL_OPTIONS 是在的，而且每个agent的参数都是齐全的。
这个时候就开始怀疑是不是启动脚本的问题，是不是有人在启动脚本中加了unset JAVA_TOOL_OPTIONS，因为当存在JAVA_TOOL_OPTIONS时，使用jdk相关的命令都会带上JAVA_TOOL_OPTIONS中的参数，造成一定的困扰，所以有时候在排查问题的时候会先unset掉这个变量，但是检查完脚本也没有问题。
最后开始咨询阿里云的工程师，怀疑是不是agent或者容器环境有问题。经过反复比较正常容器和问题容器的JAVA_TOOL_OPTIONS启动参数，发现问题容器因为多加载一个agent，JAVA_TOOL_OPTIONS多出来一段参数，去掉这段参数就能恢复正常，加上就会有问题。到这里，可能正常的思路都是怀疑是多出来的参数造成的。但在排查其他正常容器时发现，有的容器即使有这一段参数也能正常启动。
这个时候，阿里云的工程师怀疑是不是参数太长导致的，因为有问题的容器的应用名字比较长，于是我们开始测试，发现确实是这个问题，如下图所示。随后确定了问题所在，jdk8 在加载默认环境变量时会检查长度，当大于1024字节时就会加载失败。
环境变量
在jdk相关的环境变量中，有两种默认的环境变量 JAVA_TOOL_OPTIONS 和 _JAVA_OPTIONS。
JAVA_TOOL_OPTIONS：在jdk8及之前版本中，该变量是最标准的，所有虚拟机都能识别和应用的环境变量，在jdk9之后被JDK_JAVA_OPTIONS所取代。该变量限制1024字节，在不同虚拟机中表现不一样，有的是加载失败，有的是截取一段。
_JAVA_OPTIONS：也是默认的环境变量，但是它是JVM厂家自定义的，可以覆盖JAVA_TOOL_OPTIONS，但各厂家的命名不同，_JAVA_OPTIONS是Oracle的JVM，而IBM的则是用IBM_JAVA_OPTIONS。
因此为避免出现问题，我们应该尽量避免使用默认的环境变量，通常情况下可以在脚本中自定义启动变量如 JAVA_OPTS、SPRINGBOOT_OPTS等等。然后在启动java时显式的指定启动参数。
java [-options] -jar xxx.jar [args…]
可以写成
JAVA_OPTS="[-options]"
JAVA_ARGS="[args…]"
java ${JAVA_OPTS} -jar xxx.jar ${JAVA_ARGS}
