In the book Java 8 In Action, section 7.1.1, the authors state that a stream can benefit from parallel processing by adding the function .parallel(). They provide a simple method called parallelSum(int) to illustrate this. I was curious to see how well it worked so I executed this code:
package lambdasinaction.chap7;
import java.util.stream.Stream;
public class ParallelPlay {
public static void main(String[] args) {
System.out.println(parallelSum(100_000_000));
}
public static long parallelSum(long n) {
return Stream.iterate(1L, i -> i + 1)
.limit(n)
.parallel()
.reduce(0L, Long::sum);
}
}
To my surprise, I received this error:
Exception in thread "main" java.lang.OutOfMemoryError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.SliceOps$1.opEvaluateParallelLazy(Unknown Source)
at java.util.stream.AbstractPipeline.sourceSpliterator(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.reduce(Unknown Source)
at lambdasinaction.chap7.ParallelPlay.parallelSum(ParallelPlay.java:15)
at lambdasinaction.chap7.ParallelPlay.main(ParallelPlay.java:8)
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.stream.SpinedBuffer.ensureCapacity(Unknown Source)
at java.util.stream.Nodes$SpinedNodeBuilder.begin(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.SliceOps$SliceTask.doLeaf(Unknown Source)
at java.util.stream.SliceOps$SliceTask.doLeaf(Unknown Source)
at java.util.stream.AbstractShortCircuitTask.compute(Unknown Source)
at java.util.concurrent.CountedCompleter.exec(Unknown Source)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
I am running Java 1.8.0_45 on Windows 7, SP1 with a four-core processor. What's going on?
Here you create an infinite stream and limit it afterwards. There are known problems about processing infinite streams in parallel. In particular there's no way to split the task to equal parts effectively. Internally some heuristics are used which are not well suitable for every task. In your case it's much better to create the finite stream using LongStream.range:
import java.util.stream.LongStream;
public class ParallelPlay {
public static void main(String[] args) {
System.out.println(parallelSum(100_000_000));
}
public static long parallelSum(long n) {
return LongStream.rangeClosed(1, n).parallel().sum();
}
}
In this case Stream engine knows from the very beginning how many elements you have, so it can split the task effectively. Also note that using the LongStream is more effecient as you will have no unnecessary boxing.
In general avoid infinite streams if you can solve your task with finite ones.
Related
I have a problem with Java source code generation of Modisco java model.
I used this guide below in Modisco Documentation :
https://help.eclipse.org/2018-12/topic/org.eclipse.modisco.java.doc/mediawiki/java_generation/user.html?cp=67_0_1_1_2
firstly, I imported the plugin org.eclipse.gmt.modisco.java.generation in the workspace
then I added a class in src folder like this :
import java.io.File;
import java.io.IOException;
import java.util.*;
import org.eclipse.emf.common.util.URI;
import org.eclipse.gmt.modisco.java.generation.files.GenerateJavaExtended;
public class Generation {
public static void main(String[] args) throws IOException {
GenerateJavaExtended javaGenerator = new GenerateJavaExtended(URI.createFileURI("mymodel.xmi"),
new File("myOutputFolder"), new ArrayList<Object>());
javaGenerator.doGenerate(null);
}
}
But When I run this code as Java Application, I get this error :
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 67, Size: 1
at java.util.ArrayList.rangeCheck(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.eclipse.emf.ecore.impl.EPackageImpl.eObjectForURIFragmentNameSegment(EPackageImpl.java:1970)
at org.eclipse.emf.ecore.impl.EModelElementImpl.eObjectForURIFragmentSegment(EModelElementImpl.java:473)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject(ResourceImpl.java:811)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObject(ResourceImpl.java:787)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XMLHandler.java:2868)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XMLHandler.java:2773)
at org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAttribs(SAXXMIHandler.java:79)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2247)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTypeName(XMLHandler.java:2150)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:2085)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHandler.java:151)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1868)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:1048)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:82)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:1026)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:720)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:190)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:261)
at org.eclipse.acceleo.model.mtl.resource.EMtlResourceImpl.doLoad(EMtlResourceImpl.java:93)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1563)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1342)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
at org.eclipse.acceleo.common.utils.ModelUtils.load(ModelUtils.java:391)
at org.eclipse.acceleo.common.utils.ModelUtils.load(ModelUtils.java:356)
at org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.initialize(AbstractAcceleoGenerator.java:485)
at org.eclipse.gmt.modisco.java.generation.files.GenerateJava.<init>(GenerateJava.java:92)
at org.eclipse.gmt.modisco.java.generation.files.GenerateJavaExtended.<init>(GenerateJavaExtended.java:39)
at Generation.main(Generation.java:13)
How can I transform my java model back into the original Java source code?
My used tools:
Eclipse Modeling tools 2018-12 (4.10.0)
MoDisco SDK (1.2.0)
JRE 1.8.0_202
You may find an answer in the duplicate posting of this message at https://www.eclipse.org/forums/index.php?t=msg&th=1098046&goto=1804354&#msg_1804354
I am trying to pop up a custom dialog box. When I try calling the method to do that on the EDT I get the following error:
Exception in thread "AWT-EventQueue-0" java.lang.Error: Unresolved compilation problem:
at danind.com.gmail_coem.ui.CredentialEditor.promptPossibleDialog(CredentialEditor.java:29)
at danind.com.gmail_coem.ui.HomeScreen$ConfigureDatabase.<init>(HomeScreen.java:281)
at danind.com.gmail_coem.ui.HomeScreen.configureDatabase(HomeScreen.java:230)
at danind.com.gmail_coem.ui.HomeScreen.lambda$1(HomeScreen.java:105)
at danind.com.gmail_coem.ui.HomeScreen$$Lambda$7/2092062410.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
After cleaning up my project in Eclipse, and doing some isolation tests I figured out that calling the method on the EDT was what caused the problem. When I moved the method to the background thread it worked, but I don't want that since I want to create my dialog GUI on the EDT.
//Creates compilation error
private class ConfigureDatabase extends SwingWorker<Void, String[]>
{
private CredentialEditor instance;
public ConfigureDatabase()
{ //Runs on EDT
this.instance = CredentialEditor.promptPossibleDialog(true);
}
#Override
protected Void doInBackground()
{ //Runs in background thread
try(Database database = CredentialEditor.getCredentials(instance))
{
//code
}
}
}
vs
//Runs just fine, but dialog GUI is not on EDT
private class ConfigureDatabase extends SwingWorker<Void, String[]>
{
#Override
protected Void doInBackground()
{ //Runs in background thread
try(Database database = CredentialEditor.getCredentials(CredentialEditor.promptPossibleDialog(true)))
{
//code
}
}
}
The method in question:
public static CredentialEditor promptPossibleDialog(boolean reset)
{
if(reset || ConnectionPool.getInstance() == null)
{ //Checks to see if a dialog box needs to be created.
if(SwingUtilities.isEventDispatchThread())
{ //Checks to make sure the thread is on the EDT.
return new CredentialEditor();
}
else
{ //If it's not on the EDT throw an exception warning.
throw new IllegalStateException("Must run on EDT!");
}
}
return null; //If no dialog box needs to be created return nothing.
}
To be more detailed about the problem it seems simply just calling the method causes problems. It's not setting the instance variable or anything inside the method, it's just calling that static method in the EDT specifically. In fact, the stacktrace points to the line where it's simply stating the method, as in, the line where it says public static CredentialEditor promptPossibleDialog(boolean reset)
So what is causing the error and if I can't get around it how can I run my GUI code on the EDT even if the method for it is being called on a background thread?
Try running your dialog directly on EDT.
public ConfigureDatabase()
{
//some code
this.instance = CredentialEditor.promptPossibleDialog(true); //This is line 281
}
This means you are running the dialog in the worker thread, which is not a good idea. Worker Threads are mostly, afaik, for non interactive background tasks. if you must run a dialog from within a worker thread, you must separately start it of in the EDT like:
public ConfigureDatabase()
{
SwingUtilities.invokeLater(new Runnable() { //or if you must wait for its end, use invokeAndWait
public void run() {
CredentialEditor.promptPossibleDialog(true); //This is line 281
}
});
}
This should work. It would be more helpful if would provide a full SSCE, at first how you execute your Worker.
Also dialogs are for interacting with the user and bringing back a result. Saving the dialog in an instance is therefor not the best thing to do. instead store its result or rethink your design.
see here, an example:
Note: calling get on the Event Dispatch Thread blocks all events,
including repaints, from being processed until this SwingWorker is
complete.
When you want the SwingWorker to block on the Event Dispatch Thread we
recommend that you use a modal dialog.
For example:
class SwingWorkerCompletionWaiter extends PropertyChangeListener {
private JDialog dialog;
public SwingWorkerCompletionWaiter(JDialog dialog) {
this.dialog = dialog;
}
public void propertyChange(PropertyChangeEvent event) {
if ("state".equals(event.getPropertyName())
&& SwingWorker.StateValue.DONE == event.getNewValue()) {
dialog.setVisible(false);
dialog.dispose();
}
}
}
Run as:
JDialog dialog = new JDialog(owner, true);
swingWorker.addPropertyChangeListener(
new SwingWorkerCompletionWaiter(dialog));
swingWorker.execute();
//the dialog will be visible until the SwingWorker is done
dialog.setVisible(true);
Specified by: get in interface Future Returns: the computed result
Throws: InterruptedException - if the current thread was interrupted
while waiting ExecutionException - if the computation threw an
exception
You are stumbling over the Eclipse feature of allowing to run code even if it has compile errors, which does more harm than any good, imho. You may consider turning it off. However, what you have to understand is that there is no use in looking at the line number of the stack trace as that won’t necessarily tell you the line number of the compilation error but the line number where the exception has been generated at runtime.
There is no attempt to compile your code when it runs. Instead the compiler has generated code that will throw that exception unconditionally once the execution reaches the piece of code which Eclipse couldn’t compile. And so it hasn’t anything to do with the thread your code runs in. Since the spurious compiler error appears within CredentialEditor it’s unbelievable that modifications made at the caller shall change whether it compiles correctly or not. However since the code throws IllegalStateException when called in the background threads but you say that it works in your second scenario it seems that there are changes you didn’t tell us about.
On the other hand, the behavior doesn’t have to look logical if it’s caused by a bug. Normally, the exception contains the compiler error but the empty line in you stack trace perfectly matches the observed behavior that the IDE didn’t tell you about that error. So you hit a bug where there either a compiler error is assumed where none exists or that a compiler error exists for which the message is missing.
Hitting a compiler bug is not that surprising considering what you failed to mention, that you are using Java 8 and even actively use the new features. Eclipse’s Java 8 support is … well … has much room for improvements. Just check whether you are really using the most recent Eclipse version. If you are using or if the problem remains after updating I recommend you create a minimal example that reproduces the problem and doesn’t depend on any other (3rd party) classes and file a bug report to the Eclipse team.
While trying to use ProGuard (4.9) to obfuscate and optimise a desktop application everything works up until I use something from an external library such as JSoup.connect("http://google.com/").get();. I would get the following error:
Exception in thread "Thread-2" java.lang.ExceptionInInitializerError
at org.jsoup.b.l.<clinit>(Unknown Source)
at org.jsoup.b.f.<init>(Unknown Source)
at org.jsoup.b.e.<init>(Unknown Source)
at org.jsoup.c.bh.b(Unknown Source)
at org.jsoup.c.bh.a(Unknown Source)
at org.jsoup.c.b.a(Unknown Source)
at org.jsoup.c.D.a(Unknown Source)
at org.jsoup.a.a.a(Unknown Source)
at org.jsoup.a.i.e(Unknown Source)
at org.jsoup.a.e.a(Unknown Source)
at package.a.a(Unknown Source)
at package.a.b(Unknown Source)
at package.w.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Unknown Source)
at java.util.Properties.load0(Unknown Source)
at java.util.Properties.load(Unknown Source)
at org.jsoup.b.k.d(Unknown Source)
at org.jsoup.b.k.<clinit>(Unknown Source)
... 14 more
I have tried searching for a solution but the answer would always be for an android application. With no luck I have attempted the following:
Turn off Use mixed-class names
Added to config -keep public enum * { public static **[] values(); public static ** valueOf(java.lang.String); }
Recently, going through with this process using ProGuard 5.2, not much has changed. Here is the updated process to fixing the issue:
Go to the Obfuscation tab.
Go to the bottom for Keep additional class names and class member names
Click on Add... to the right
Go down to Extends/implements class and type in your library matching the examples below then press Ok. Repeat for every library.
For JSoup: org.jsoup.**
For Apache Commons Net: org.apache.commons.net.**
For SwingX: org.jdesktop.**
For GSON: org.google.gson.**
Go to the Information tab.
Turn off Skip non-public library class members
Turn on Ignore warnings about possibly erroneous input
Process!
We are developing java applet and embedding it in our web pages. When the applet is loaded via HTML APPLET tags, the browser/JVM prompts the user to allow it to run. When we hit cancel, the java console indicates the following exception:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$12.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getenv.TEMP)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.System.getenv(Unknown Source)
at downLoadApp.<clinit>(downLoadApp.java:15)
... 21 more
Exception: java.lang.RuntimeException: java.lang.ExceptionInInitializerError
Now, I realize it's most likely because the class java tried to load was prevented from loading, and therefore the exception is thrown, but how do we gracefully handle this situation in the browser? I'd like to detect that the applet was denied and post a reasonable response to the condition, but I'm unaware of how to catch this exception since it appears to have been thrown by the JVM in reaction to not getting the jar file to load rather than code written in it...
Ideas?
Thanks!
You can catch the access control exception by putting the call to System.getenv in downLoadApp.java line 15 in a try-catch statement. That is, instead of this:
static String tmp = System.getenv("TEMP");
you should have:
static String tmp;
static {
try {
tmp = System.getenv("TEMP");
} catch (java.security.AccessControlException ace) {
// tmp is not set, maybe use some default value?
}
}
Do you call System.getenv("TEMP") somewhere in the static context of the downLoadApp class? Most probably this is in the initializer of a static field, but it could be in a static code block.
This is the place where it fails (a java.security.AccessControlException is thrown). The rest of the stack trace are errors following from that. You need to catch this exception to detect that you don't have the appropriate permissions.
As you can't catch exceptions of static field initializers, you need to move the call to getenv into a method or a static code block.
I don't think that you can catch this exception as this is thrown by JVM while loading applet.
I'm having difficulties in understanding the thread dump I got from jstack for a Spring MVC web application running on Tomcat 6 (java 1.6.0_22, Linux).
I see blocking threads (that cause other threads to wait) which are blocked themselves, however the thread dump doesn't tell me why or for which monitor they are waiting.
Example:
"TP-Processor75" daemon prio=10 tid=0x00007f3e88448800 nid=0x56f5 waiting for monitor entry [0x00000000472bc000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3067)
- locked <0x00007f3e9a0b3830> (a java.lang.Class for org.catapultframework.resource.ResourceObject)
at java.lang.Class.getAnnotation(Class.java:3029)
...
I.e. I am missing the "waiting to lock ..." line in the stack trace. Apparently the thread locks a Class object, but I don't see why the thread itself is blocked.
The thread-dump does not contain any hints for deadlocks.
What can I do to identify the locking monitor?
Thanks,
Oliver
Apparently the situation where we observed these kinds of blocked threads were related to heavy memory consumption and therefore massive garbage collection.
This question Java blocking issue: Why would JVM block threads in many different classes/methods? describes a similar situation, so I believe these threads were simply blocked by the garbage collector.
(Anyway, after solving the memory issue this problem with the blocking threads was gone.)
Check if the finalizer thread is blocked or waiting.
During a GC sweep, the GC will "stop the world" to perform its cleanup. The definition of "world" depends on the garbage collector being used and context. It may be a small cluster of threads or all of them. Before officially collecting garbage, GC will invoke the object's finalize().
If you are in the undesirable situation where you are implementing finalizer methods, the finalization code may be blocking it from finishing and the 'world' stays stopped.
This is most obvious when seeing lots of threads being permanently-blocked by some unknown magic force: Look up the code where the blocking occurs and it will make no sense; there is no blocking code to be found anywhere near it and the dumps will not divulge what monitor it is waiting on because there isn't one. The GC has paused the threads.
I had a similar problem just now using an Applet in Google Chrome.
In short:
The BLOCKED threads can be blocked when the VM needs to load a class.
When the process of loading the class itself is blocked by something a freeze for the whole app can occur.
In Detail:
I had the following scenario:
I am using an Applet in Chrome with codebase = folder to single class-files (no jar)
The Website passes focus-events to the applet using LiveConnect
The incoming JS-calls are using an Executor with new Runnable() ... to detach the calls in order to reduce the wait times and thus hangs in JS.
That's where the problem occured!
Explanation:
The new Runnable() is an annonymous inner class which was not loaded before the JS call happened.
The JS call therefore triggers the class load.
But now the class loader is blocked because it needs to talk to the browser (i am guessing) via the same queue or mechanism that is processing the incoming JS call.
Here is the blocked thread that is trying to load the class:
"Thread-20" daemon prio=4 tid=0x052e8400 nid=0x4608 in Object.wait() [0x0975d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at sun.plugin2.message.Queue.waitForMessage(Unknown Source)
- locked <0x29fbc5d8> (a sun.plugin2.message.Queue)
at sun.plugin2.message.Pipe$2.run(Unknown Source)
at com.sun.deploy.util.Waiter$1.wait(Unknown Source)
at com.sun.deploy.util.Waiter.runAndWait(Unknown Source)
at sun.plugin2.message.Pipe.receive(Unknown Source)
at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source)
at sun.plugin2.main.client.MessagePassingExecutionContext.getCookie(Unknown Source)
at sun.plugin2.main.client.PluginCookieSelector.getCookieFromBrowser(Unknown Source)
at com.sun.deploy.net.cookie.DeployCookieSelector.getCookieInfo(Unknown Source)
at com.sun.deploy.net.cookie.DeployCookieSelector.get(Unknown Source)
- locked <0x298da868> (a sun.plugin2.main.client.PluginCookieSelector)
at sun.net.www.protocol.http.HttpURLConnection.setCookieHeader(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
- locked <0x2457cdc0> (a sun.net.www.protocol.http.HttpURLConnection)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.DeployCacheHandler.get(Unknown Source)
- locked <0x245727a0> (a java.lang.Object)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
- locked <0x24572020> (a sun.net.www.protocol.http.HttpURLConnection)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
- locked <0x299726b8> (a sun.plugin2.applet.Applet2ClassLoader)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
- locked <0x299726b8> (a sun.plugin2.applet.Applet2ClassLoader)
at java.lang.ClassLoader.loadClass(Unknown Source)
As you can see it is waiting for a message --> waitForMessage().
At the same time there is our incoming JS call being BLOCKED here:
"Applet 1 LiveConnect Worker Thread" prio=4 tid=0x05231800 nid=0x1278 waiting for monitor entry [0x0770e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at MyClass.myMethod(MyClass.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.Trampoline.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MethodInfo.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass$MemberBundle.invoke(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke0(Unknown Source)
at sun.plugin2.liveconnect.JavaClass.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$DefaultInvocationDelegate.invoke(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.doObjectOp(Unknown Source)
at sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$LiveConnectWorker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Additional other threads were blocked in the same manner. I suppose all subsequent class-load requests were blocked by the first blocked class-loading thread.
As mentioned before, my guess is that the class-loading process is blocked by the pending JS call, which by itself is blocked by the missing class to be loaded.
Solutions:
Trigger loading all relevant classes in the constructor of the applet before any calls can be made from JS.
It might help if the class-files are not being loaded individually, but from a jar-file. The theory behind this is: The class loader does not need to talk to the browser to load the classes from the jar-file (which would be
In combination with 1.: Use a dynamic Proxy class to wrap all incoming JS calls and run them independently in an Executor.
My implementation for #3:
public class MyClass implements JsCallInterface
{
private final JsCallInterface jsProxy;
private final static interface JsCallInterface
{
public void myMethod1Intern(String param1, String param2);
}
private final class JsCallRunnable implements Runnable
{
private final Method method;
private final Object[] args;
private JsCallRunnable(Method method, Object[] args)
{
this.method = method;
this.args = args;
}
public void run()
{
try
{
method.invoke(MyClass.this, args);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
public MyClass()
{
MyUtilsClass.class.getName(); // load class
JsCallRunnable.class.getName(); // load class
InvocationHandler jsCallHandler = new InvocationHandler()
{
public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable
{
MyUtilsClass.executeInExecutor(new JsCallRunnable(method, args));
return null;
}
};
jsProxy = (JsCallInterface) Proxy.newProxyInstance(MyClass.class.getClassLoader(), new Class<?>[] { JsCallInterface.class }, jsCallHandler);
}
public void myMethod1(String param1, String param2)
{
jsProxy.myMethod1Intern(param1, param2);
// needs to be named differently than the external method or else the proxy will call this method recursively
// alternatively the target-class in "method.invoke(MyClass.this, args);" could be a different instance of JsCallInterface
}
public void myMethod1Intern(String param1, String param2)
{
// do actual work here
}
}
This is a cosmetic bug in Oracle's HotSpot JVM - in your stack trace where you see - locked <0x00007f3e9a0b3830> it should actually say - waiting to lock <0x00007f3e9a0b3830>.
See this bug for more details.