I'm doing some routine in Java (1.5)+Swing, that damands some time. How the best way to implement this routing outside the swing thread, to avoid UI freezing?
Thanks in advance
At first blush, look at the SwingWorker class. When you want to make the code more robust and testable, you probably want to move away from that, but it is a good enough first start.
You can get a version for Java 1.5 here. With 1.6 it is part of the standard API.
Using SwingWorker is of course good idea and I recommend that. Also writing custom javax.swing.Timers and java.lang.Threads .
But don't forget to use profiler - it can help you to find many problems. Like Swing is often having trouble with "dead" Listeners holding some references which can not be garbage collected (resulting in very slow responses or freezing of UI or even memory leaks). Profiler will help you to investigate memory needs of specific situations when using your application and therefore you might be able to do fine tuning of your app.
Resolved as comment:
"This could help: stackoverflow.com/questions/2564388/javas-swing-threading – Andreas_D Jul 5 at 22:01"
Related
I'm coming from VB6 and I'm new to Java. In VB6, DoEvents gives up the processor and allows it to process other threads. Is there a similar thing in Java? How do I use it?
gives up the processor and allows it to process other threads.
Thread#yield() is the java counterpart to relinquish the control of the processors voluntarily.
From the javadoc for java.lang.Thread#yield():
A hint to the scheduler that the current thread is willing to yield its current use of a processor. The scheduler is free to ignore this hint.
Yield is a heuristic attempt to improve relative progression between threads that would otherwise over-utilise a CPU. Its use should be combined with detailed profiling and benchmarking to ensure that it actually has the desired effect.
It is rarely appropriate to use this method. It may be useful for debugging or testing purposes, where it may help to reproduce bugs due to race conditions. It may also be useful when designing concurrency control constructs such as the ones in the java.util.concurrent.locks package.
Note:
In case of Java based desktop UI frameworks like Swing, RIM's UI application, there are ways to modify the UI using invokeLater() type of semantics.
Having moved from VB6 to Java myself and having searched for an answer to this very same question at the time, I can tell you that I had to change my way of thinking about how to do things. The need for "doEvents" is most likely due to you attempting to write a Java program in the same way you wrote VB6 or an attempt to port a VB6 project "line by line" to Java. Neither is a good idea. Take a good look at the swing tutorial (if this is about UI) and the threading tutorial whether it is UI or not. Pay a close attention to and try to understand how the Event Dispatch thread works. I found the Java tutorials to be a great starting place, they are now located at Oracle: http://docs.oracle.com/javase/tutorial/ look at the samples and read the code, they are a good place to learn/experiment
You need to start thinking in Java and not translate VB6 to Java, it took me a while to get there but not too long and overcoming the need for "doEvents" will take you a long way down that path if you understand the way around it. Good luck, and welcome to Stackoverflow, this is a great place to look for help!
Does anybody know of a way to lock down individual threads within a Java process to specific CPU cores (on Linux)? I've done this in C, but can't find how to do this in Java. My instincts are that this will require a JNI call, but I was hoping someone here might have some insight or might have done it before.
Thanks!
You can't do this in pure java. But if you really need it -- you can use JNI to call native code which do the job. This is the place to start with:
http://ovatman.blogspot.com/2010/02/using-java-jni-to-set-thread-affinity.html
http://blog.toadhead.net/index.php/2011/01/22/cputhread-affinity-in-java/
UPD: After some thinking, I've decided to create my own class for this: ThreadAffinity.java It's JNA-based, and very simple -- so, if you want to use it in production, may be you should spent some time making it more stable, but for benchmarking and testing it works well as is.
UPD 2: There is another library for working with thread affinity in java. It uses same method as previously noted, but has another interface
I know it's been a while, but if anyone comes across this thread, here's how I solved this problem. I wrote a script that would do the following:
"jstack -l "
Take the results, find the "nid"'s of the threads I want to manually lock down to cores.
Taskset those threads.
You might want to take a look at https://github.com/peter-lawrey/Java-Thread-Affinity/blob/master/src/test/java/com/higherfrequencytrading/affinity/AffinityLockBindMain.java
IMO, this will not be possible unless you use native calls. JVM is supposed to be platform independent, any system calls done to achieve this will not result in a portable code.
It's not possible (at least with plain Java).
You can use thread pools to limit the amount of threads (and therefore cores) used for different types of work, but there is no way to specify a core to use.
There is even the (small) possibility that your Java runtime doesn't support native threading for your OS or hardware. In this case, green threads are used and only one core will be used for the whole JVM.
I have a Java project, in which I have to achieve parallelization through OpenMP technology (that is, I have to, somehow, make a bridge between C/C++ and Java). So far I was told about using JNI for integrating C/C++ code in java, but, also I was suggested to use JaMP instead. I don't know much about these techniques/frameworks, so my question is, which is less pain to use, and, generally, how can I implement OpenMP stuff in Java code? Can I achieve the same functionality using only Java threads (without using OpenMP)? I'm a beginner in this domain, so absolutely any help is much appreciated.
Hint: the project is to build a collaborative graphic editor, by "putting" onto one core the interactions between the server and the clients, and "putting" onto another core the effective graphic processing.
From your brief and slightly confusing explanation of your project I don't see any need for you to be using OpenMP at all. All that you want to do can be done entirely within Java which has good (enough) facilities for concurrent programming.
OpenMP was designed for a completely different type of 'concurrent' program -- really for parallel programs; at its heart it's for spreading loop iterations across processors. This is not a good fit to your problem.
If you have been told that you must use Java and OpenMP then I suppose you must. If this is so, go with JaMP. Only if someone holds a gun to your head should you set out on the path of Java+JNI+C/C+++OpenMp.
Futures can also be given a look for your project.
Which I think is not used by many traditional programmers for parallelizing their work.
I'm just starting with J2ME and lcdui, and I'm looking at some sample code that calls methods on lcdui objects from a worker thread.
In my experience with desktop GUI toolkits, this is usually forbidden - is lcdui different? Is it really OK to do this?
(I've Googled for an answer to this question but not found anything - a link to a defintive answer in some official documentation would be excellent!)
LCDUI is a bit of a funny one, what you can and can't do often depends on the implementation. I've written apps for BlackBerry that don't have a problem with accessing UI objects from a background thread (except the usual threading problems that you create yourself), but I'm pretty sure some other platforms will forbid this.
If you're concerned about this, or it's causing you issues, you might want to look at using javax.microedition.lcdui.Display.callSerially(Runnable). This executes the given Runnable object in the UI thread (if there is such a thing in LCDUI) and serializes it with other UI events and paint operations. You can read more about it in the J2ME API docs.
Using the javax.microedition.lcdui classes, thread-safety is supposedly one of the goals of the UI classes according to the Concurrency section of this documentation. As Rory indicated, it is entirely possible that different vendors implemented this as more of a "suggestion" rather than a rule.
At one time, I was looking for similar information, but was also unable to find the magic phrasing to offer Google to get good results.
Best of luck!
If we have 300 classes in an application, is it possible to monitor how many instances of each class we have at a given time? Is it possible to know how much memory each instance is consuming?
Thanks
JDK 1.6 includes a tool called jvisualvm, which allows you to view lots of information about your running Java program, including memory usage, threads, etc. You could also use a profiler to see this kind of information. The profiler in NetBeans looks a lot like JVisualVM.
I personally like Yourkit. It has a very good UI and comes with a 30 day trial. The details are also pretty extensive.
The online help document in that site should help you on how to set things up for running it.
use profiler4j or pmd
personally i like profiler4J for its ease of use and simple graphics :)
use jvisualvm.exe it is part of the JDK6
Most profilers will give you this information. I'm personally familiar with JProfiler, but I expect any worthwhile profiler would let you do this.
For a more low-tech solution, you could even trigger a heap dump from your application and then look through it with an application like jhat. The interface leaves a lot to be desired, though, and profilers would be much more comfortable to use in any non-trivial case.
Edit: here is an example of the memory screen for JProfiler, and you can also investigate the reference chain.
You could use a Java profiler, depending on which web container (if it's a web-app) you're deploying to you can try alot of different profilers: http://java-source.net/open-source/profilers