Question

我的独立java应用程序使用nio选择器进行套接字连接，ibm mq类（版本7.0.1.3）用于侦听队列和主题，ORACLE_JDBC_DRIVER用于db.Three不同的线程运行用于套接字，队列和主题连接。队列和主题侦听器正在异步模式下工作。我在eclipse mars中制作了可运行的jar，Oracle jdk版本1.7.03。当我在我的窗口系统（64位，16gb ram，intel core-i7）中启动应用程序时，它的工作正常，它消耗了大约0.3％的CPU。但是当我在VMware IDE CDR10中启动应用程序在linux（64位）上运行时，它会占用90-120％的CPU。 VM中的openJDK版本安装是1.7.0_03-icedtea（64位）。

堆栈分析后怀疑CPU占用率高

VM周期性任务线程 - 消耗40-50％的cpu
VM线程 - 消耗25-30％的cpu
WebSphere MQ跟踪监视器 - 消耗25-30％的cpu。

问题：

为什么线程1和2消耗高CPU以及如何优化它。？
如何停止线程3，是否会影响JMS的功能。
是否需要更改VMware的配置才能运行java应用程序？
nio选择器会导致高CPU消耗吗？

提前谢谢你。下面是我使用jstack命令的堆栈跟踪。全线程转储OpenJDK 64位服务器VM（22.0-b10混合模式）：

"Attach Listener" daemon prio=10 tid=0x00007f1d1c001000 nid=0x1280 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" prio=10 tid=0x00007f1d3c007000 nid=0xc47 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"ServerThread" prio=10 tid=0x00007f1d3c3b0800 nid=0xcd7 runnable [0x00007f1d13b76000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
        at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
        at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
        - locked <0x00000000ee0f17e8> (a sun.nio.ch.Util$2)
        - locked <0x00000000ee0f17d8> (a java.util.Collections$UnmodifiableSet)
        - locked <0x00000000ee0f09a8> (a sun.nio.ch.EPollSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102)


"RcvThread: com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection[qmid=ADS.QUEUE.MANAGER_2014-03-19_11.32.54           ,fap=10,peer=ads1sitsvr1/10.106.95.15,localport=43233,ssl=no]" daemon prio=10 tid=0x00007f1d00001800 nid=0xcb1 runnable [0x00007f1d13c77000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:150)
        at java.net.SocketInputStream.read(SocketInputStream.java:121)
        at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.receive(RemoteTCPConnection.java:1409)
        at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:737)
        at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:701)
        at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:146)
        at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209)
        at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100)
        at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224)
        at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298)
        at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220)

"JMSCCThreadPoolMaster" daemon prio=10 tid=0x00007f1d3c4e3000 nid=0xcaf in Object.wait() [0x00007f1d38159000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000ee101cf8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:503)
        at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$WorkQueueManagerThread.waitForNotification(WorkQueueManagerImplementation.java:651)
        - locked <0x00000000ee101cf8> (a java.lang.Object)
        at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$WorkQueueManagerThread.waitForNotification(WorkQueueManagerImplementation.java:621)
        at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$WorkQueueManagerThread.run(WorkQueueManagerImplementation.java:887)

"WebSphere MQ Trace Monitor" daemon prio=10 tid=0x00007f1d3c31e800 nid=0xc77 sleeping[0x00007f1d40305000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at com.ibm.mq.commonservices.internal.utils.TraceMonitor.run(TraceMonitor.java:123)

"Service Thread" daemon prio=10 tid=0x00007f1d3c128800 nid=0xc70 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f1d3c126000 nid=0xc6e waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f1d3c123000 nid=0xc6b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f1d3c121000 nid=0xc6a runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f1d3c0cc000 nid=0xc5f in Object.wait() [0x00007f1d40ebe000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000ee158730> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
        - locked <0x00000000ee158730> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)

"Reference Handler" daemon prio=10 tid=0x00007f1d3c0c9800 nid=0xc5e in Object.wait() [0x00007f1d40fbf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000ee158760> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:503)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
        - locked <0x00000000ee158760> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00007f1d3c0c1000 nid=0xc5c runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f1d3c011800 nid=0xc4d runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f1d3c013800 nid=0xc4f runnable

"VM Periodic Task Thread" prio=10 tid=0x00007f1d3c133000 nid=0xc72 waiting on condition

JNI global references: 273

VM周期性任务线程，VM线程和WebSphere MQ跟踪监视器在Linux中消耗100 +％cpu

0 个答案: