除了gc stop the world safepoints之外，jvm可以在safepoint中停止java应用程序还有很多原因。评估safepoints stop的原因之一是有保证的safepoint间隔。
我们能预测什么时候保证安全点停车吗？或者是最近拍的？
为什么我需要它？我在线程中进行共享内存文件预处理。如果在评估safepoint停止时进行预触，则会使到safepoint的时间更长。如果我只能等到安全点评估之后。
除了gc stop the world safepoints之外，jvm可以在safepoint中停止java应用程序还有很多原因。评估safepoints stop的原因之一是有保证的safepoint间隔。
我们能预测什么时候保证安全点停车吗？或者是最近拍的？
为什么我需要它？我在线程中进行共享内存文件预处理。如果在评估safepoint停止时进行预触，则会使到safepoint的时间更长。如果我只能等到安全点评估之后。
1条答案
按热度按时间stszievb1#
清理安全点（也称为“保证安全点”）仅在有一些清理工作要做时发生，例如jvm需要清空空闲监视器或清除内联缓存缓冲区。没有办法预测这样的安全点。但好消息是你不需要这么做。
所以，原来的问题是防止长时间的安全点暂停时，预触摸内存Map的文件，对吗？解决方法是以一种完全不受安全点影响的方式对其进行预触。
调用jni方法时，线程将切换到
in_native州。jvm不等待处于这种状态的线程。所以，只需将预触移到本机方法，就不会影响安全点，不管它们是否发生。一种选择是使用常规的filechannel api。e、 g.不是访问Map的bytebuffer，而是通过从filechannel读取（或写入）1字节来预触摸。i/o将发生在不受安全点约束的本机方法中。
另一种选择是打电话
Unsafe.setMemory. 这是一个真正的本机方法（不是jvm内部方法），因此它也不会影响safepoint计时。