JNI->MonitorEnter 的替代方案
我遇到了一个 JNI 本机代码，它使用 JNI->MonitorEnter 和 JNI->MonitorExit JNI 调用来同步一段本机代码。但这现在已经成为瓶颈，严重影响系统吞吐量。我正在考虑使用任何同步机制来替代 JNI 的 MonitorEnter 和 MonitorExit。
您知道任何替代设计吗？
[一些链接 http://java.sun.com/docs/books/ jni/html/other.html , http://download.oracle.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp5256]
I came across a JNI Native code which uses JNI->MonitorEnter and JNI->MonitorExit JNI calls to synchronize a piece of native code. But this has now become a bottleneck and affecting the system throughput badly. I am considering any synchronization mechanisms alternate to JNI's MonitorEnter and MonitorExit.
Do you know of any alternate design?
[Some links http://java.sun.com/docs/books/jni/html/other.html , http://download.oracle.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp5256 ]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题是占用监视器所花费的时间吗？或者（在我看来更有可能）持有锁时所花费的时间？如果您需要保护一段 JNI 代码，那么您可以在那里使用单线程，因此它可能会成为瓶颈。
你能以任何方式最小化关键部分吗？你能将代码重写为线程安全的吗？
Is it the time spent taking the monitor that's the problem. Or (more likely in my view) the time spent while the lock is held? If you need to protect a piece of JNI code, then you single thread there so it's likely to become a bottleneck.
Can you minimise the critical section in any way? Can you rewrite the code to be thread-safe?