3

We profiled our application with jvisualvm and found out that it spends a lot of time in Object.wait().

How do I find the objects that this method is called for?

Chris
  • 5,584
  • 9
  • 40
  • 58
er4z0r
  • 4,711
  • 8
  • 42
  • 62
  • Is wait a static member of the object? – Roman C Sep 09 '12 at 11:51
  • Wait is a method inherited from Object. It is usually called when concurrent objects try to access a Monitor (i.e. Class with synchronize mehtods). The JVM puts the second caller into wait by calling wait(). Since it does not knoow what type the caller has it can only do Object.wait() – er4z0r Sep 09 '12 at 11:59
  • Welcome to profiling. [*Here's what actually works*](http://stackoverflow.com/a/317160/23771) and [*here's why*](http://scicomp.stackexchange.com/a/2719/1262). More [*reasons why*](http://stackoverflow.com/a/1779343/23771). – Mike Dunlavey Sep 09 '12 at 12:51
  • Those links are interesting, but for many applications application the techniques described will be overkill. Secondly, Sun (now Oracle) invested a great deal of effort into VisualVM and JConsole, so it would be silly not to use them (writing as someone who has his share of experience staring at thread dumps generated by SIGKILL). – noahlz Sep 09 '12 at 18:23
  • @noahz: If only something could be made worthwhile by just spending enough effort on it. What it really comes down to is how badly do you need the speed, because SO is full of questions and commentary to the effect: My profiler is confusing but doesn't seem to be showing me any bottlenecks, so I guess I'll assume there aren't any. – Mike Dunlavey Sep 10 '12 at 17:20

3 Answers3

1

In fact, the Java SE SDK comes with a useful class ThreadInfo which you can inspect to learn why a thread is blocked and what it is waiting on, including the full stacktrace to the wait point, and the total time in millis spent waiting.

You use this class via the java.lang.management package and specifically ManagementFactory.getThreadMXBean() You can then use this class to inspect your blocked threads programmatically.

Here is a relevant screenshot from JConsole:

enter image description here

noahlz
  • 10,202
  • 7
  • 56
  • 75
  • Sorry, I am quite a noob with JMX. Can I access this from viusalvm or do I need to write extra monitoring code? – er4z0r Sep 09 '12 at 12:41
  • Both. VisualVM uses the API to monitor the JVM, and you can use the API to write your own custom monitoring/profiling component. – noahlz Sep 09 '12 at 13:49
1

If you're not restricted to jvisualvm, in JProfiler you can right-click the object in the locking graph and inspect it in the heap walker.

enter image description here

This is for the current locking situation, but the history views will give you access to previous locking situations and there is also a monitor statistics view that will break down the monitors by their class:

enter image description here

Disclaimer: My company develops JProfiler.

Ingo Kegel
  • 46,523
  • 10
  • 71
  • 102
0

Hanging on Object.wait() is a totally legal and safe situation, which may happen, for example, when some thread is waiting for a new element in a BlockingQueue. The time spent on this waiting shouldn't affect performance of your application, unless it's a deadlock.

yegor256
  • 102,010
  • 123
  • 446
  • 597
  • I'm not saiing it is bad. I am just interested in which of my active objects is waiting. From only seeing that the system spends half the cycles in Object.wait() I cannot learn much. So the question is "who" is waiting and why ;-) – er4z0r Sep 09 '12 at 12:39
  • Time spent waiting will absolutely affect the performance of your application. – noahlz Sep 09 '12 at 13:43