OpenJ9是IBM&Eclipse开源的一款jvm。与Oracle jvm（所谓“官方”）相比，memory footprint较小，启动速度快是它的主要优势。
我们在实施过程中，主要遇到了jps, jstack无响应问题，不影响程序运行，但影响程序问题排查。本文记录了解决该问题的过程。
问题现象
jvm运行约半个月后，使用依赖jvm attach api的工具（如jps, jstack等）attach到目标jvm上，很长一段时间无响应直至SocketTimeout，无法attach成功。
出现该情况后，使用kill -3 目标jvm，触发jvm coredump之后，再次使用jps, jstack等工具进行attach，可以attach成功，并能正确返回相应调试信息。
最终结论
根本原因是centos对/tmp目录的自动清理造成。
修改/usr/lib/tmpfiles.d/tmp.conf，设置
x /tmp/.com_ibm_tools_attach/*
可以彻底解决该问题。
排查过程
首先肯定去网上找有没有类似的场景类似的问题，最后找到一个比较相近的：
https://github.com/eclipse-openj9/openj9/issues/13010
但是很不幸，这个场景是jvm停止之后残留的ipc文件导致，而我的场景中，jvm是一直正常运行着的，并未停止。所以，这个issue唯一有参考价值的地方，就是/tmp/.com_ibm_tools_attach这个目录，起码知道了这个目录是OpenJ9 jvm用于存放ipc文件的，是jps, jstack等工具依赖的关键目录。
这个时候我立马想到了/tmp目录的自动清理。运行半个月出问题，大概率是自动清理造成。于是立马查看了/tmp/.com_ibm_tools_attach这个目录之下的内容，很遗憾的发现，貌似所有进程的ipc文件都完好无损，压根就没有被清理的迹象。
其实此时离真相已经非常接近了，但对于一个从未接触过ipc的人来说，谁会发现inode中的玄机，谁会想到去查inode号呢？
所以当时，我错误地排除了文件被清理的这种可能，从OpenJ9源码入手，想找到一些线索。
OpenJ9中与attach api相关的实现有2部分，java部分和c++部分。
java部分实现主要集中在
openj9.internal.tools.attach.target包的这几个类：AttachHandler, WaitLoop, Attachment, CommonDirectory, IPC主要负责①ipc文件的管理以及②提供attach api服务，外部工具就是通过attach请求创建一个tcp连接进来，与jvm通信的。
c++部分主要通过ipc文件、共享内存、信号量等手段来实现进程间的ipc通信。
以jstack为例，具体流程如下：
目标jvm在启动后，会检查/tmp/.com_ibm_tools_attach（下文简称
common directory）这个目录下的ipc文件，如果没有或者过期则会重新创建；目标jvm在启动后，会创建1个
Attach API wait loop的线程，用于监听外部的attach请求；jstack内部开启一个ServerSocket，用于与目标jvm通信；
jstack向
common directory/jvm进程号 这个目录写入replyInfo文件，文件内容为ServerSocket的端口号jstack通过
common directory下的信号量专用文件_notifier发送信号量。注意此操作不会向文件写入内容，不会改变_notifier文件的修改日期；目标jvm收到信号量，读取
replyInfo文件获取与jstack通信的端口号，通过该端口号连接jstack；jstack与目标jvm通过端口连接后，删除
replyInfo文件，后续两者就通过tcp通信。这些过程会有很多日志，如果出现问题，可以通过：
OpenJ9 jvm参数
-Dcom.ibm.tools.attach.logging=yes可以看到java部分的日志；OpenJ9 jvm参数
-Xtrace:maximal=j9prt,output=trace.out可以看到c++部分的日志。好，说了这么多，回到之前的问题：ipc文件看上去没有被清理，为什么ipc无法正常工作？
起初我猜测信号量文件
_notifier应该会有过期时间，因为问题半个月出现一次。但是从jvm的ipc相关代码中，并没有看到设置信号量过期时间为半个月的这种逻辑出现。那问题就很诡异了，到底发生了什么，只有通过相关工具来跟踪信号量文件，才能找到真相，我这边使用的是ipcs工具。
ipcs -a
------ Semaphore Arrays --------
key semid owner perms nsems
0xd7549b54 4 root 600 152
0xd7549b55 5 root 600 152
0xd7549b56 6 root 600 152
ipcs输出的列中，我比较关心的是key和semid。semid不用过多解释，就是信号量的id，那这个key是如何生成的？
继续查看jvm代码，这个key是通过ftok()函数生成出来的，ftok会根据文件的inode号来生成，也就是说，这个key截取了_notifier文件的inode号一部分，如果文件名相同，inode号不对，是不能正常通信的。
到这里我似乎有些明白了，有没有可能出现_notifier文件被删除，但是后面又重新生成这种情况？
我把common directory整个删除，然后执行jstack，报错Error getting data from xxx...然后一看，common directory重新生成了，_notifier也重新生成了。因为重新生成的信号量文件与之前使用的信号量文件inode号不一致，所以两者的semid也肯定不一致，所以看上去文件还在，但是无法正常ipc通信，所以jstack调不通。
centos的自动清理功能是根据文件修改时间，上文说过，使用信号量文件通信，文件的修改时间是不会发生变化的，也就最终导致了_notifier文件被清理；被清理之后，我发现jstack调不通的时候，因为执行了jstack，jstack也是基于jvm运行，故_notifier文件被重新生成出来，造成了当初的错觉。
真相大白，不容易啊。
