如何防止Linux Mint上的一致java暂停模式

wil*_*ill 5 multithreading linux-mint java-8 jetty-9

我有一个在Linux Mint上运行的Java应用程序.每一分钟,程序显示一个非常明显的减速 - 暂停.暂停是一致​​的3到4秒.当我们运行同一程序的更多实例时,它们每分钟也会暂停3到4秒.每个程序在一分钟的不同时间停止.

最近更新:

在最后一次更新(下面)之后,增加线程池的线程数会看到GUI问题消失.运行大约40个小时后,我们在Jetty HttpClient 阻塞 -GET(Request.send())调用中发现线程泄漏.要解释这些机制,请使用Executor类:主线程每隔几分钟运行一次.它使用Executor运行一个独立的线程来使用HTTP GET命令Jetty来调用主机HttpClient.request.send().

运行约40小时后,HttpClient池中运行的线程数量出现峰值.所以40个小时,相同的线程运行良好.工作假设是,在那个时间,一个或多个send()调用没有完成或超时并且没有返回到调用线程.基本上这个/这些线程挂在Jetty客户端中.

jVisualMV中观察每个常规周期时,我们会看到每个周期的正常行为; 一些HttpClient线程为主机GET启动,只需几秒钟即可执行和离开.监视器上还有大约10个属于Jetty HttpClient线程池的线程,它已经"存在"了(现在)10个小时.

期望是底层客户端或网络处理存在一些错误.我很惊讶没有超时异常或编程异常.我现在可以问一些明确的问题.

  1. 里面发生的事情HttpClient可能只是挂了一个Request.send()
  2. 通话返回的超时时间是多少?我认为仍会有绝对的超时或检查锁定等(不?)
  3. I/O系统可以挂起并让调用者线程挂起 - 而Java乖乖地......
    • 然后在预定的时间触发管理器线程
    • 接下来Http.Request.send()发生了,
    • 来自池的新线程用于下一次发送(似乎已经发生).
    • 虽然早先send()陷入困境
  4. 我可以限制或其他明智地清理这些卡住的线程吗?

这是在我们增加线程池大小之前发生的.发生的事情是,"责备"变得更加集中在问题领域.我们也对基础系统持怀疑态度,因为我们还在HttpClient同一时间(非特定)时间内再次与Apache锁定.

(事先更新)......

观察到的暂停行为是JavaFX GUI不更新/刷新; 显示器的时钟(textView),setText()在冻结过程中记录了每秒两次x更新的呼叫(这是新信息).时钟不更新(在Mint Linux上),它在Windows上运行时会继续更新.为了阻止我重复自己关于GC,日志,探针等的问题,答案是一样的; 我们已经进行了数周的广泛诊断.问题无疑是Linux JVM/Linux Mint/Threads(每个JavaFX)的混合体.其他一些新数据是将线程池数量增加+2,似乎删除了冻结 - 需要进一步测试以确认并调整数字.但问题是" 两个平台之间存在差异的参数什么? "

我们已经在Windows上运行了几个程序实例,没有暂停.当我们在Mint Linux平台上运行时,我们看到了冻结,它非常一致.

该程序有几个运行线程按计划运行.一个线程打开一个http套接字的互联网.当我们评论该区域时,暂停消失.但是我们没有看到使用Windows的行为.实验指出了Mint网络I/O子系统,Linux调度,Linux Java 8 JVM或两者之间的某些交互所特有的东西.

正如你可能猜到的那样,我们正在把这头发撕掉.例如,我们关闭了日志记录,暂停仍然存在.我们恢复了日志记录,只是对http服务器进行了一次调用,每60秒暂停一次,同样的第二次计数.即使我们不进行其他处理,也会发生这种情况 我们尝试了不同的http库等.似乎非常清楚它是在JVM或Linux中.

有谁知道解决这个问题的方法?