We Keep Coding

java/swing: gui froze, no thread suspended

To start with it is a huge application and the problem concerns many lines so I can't really attach any code.
After a change that consists mainly of clearing and re-adding elements to some collection, swing GUI of the application freezes. That freeze doesn't happen while that added code is executed but some time afterwards. What makes it strange is that no thread is suspended.
My question is whether the infinite loop is the only explanation of this problem. It feels unlikely to me that this is the case because the added code finishes without problems.
There may be some unsynchronized collection access issue, but I don't see it leading to that situation. It doesn't look also like we are dealing with a deadlock coming from synchronization problem since no thread is suspended.

In the end it is a deadlock.
My team leader told me that threads waiting on monitor (on "synchronized") aren't shown in eclipse as suspended. He found some two threads and asked to pause them. Then I saw they are waiting for each other to release the occupied monitors.
The deadlock isn't fault of the code I entered. It's just that the change I made revealed wrong synchronization in some other place.
Thank you all for trying to help me, I really appreciate it. It is my first question on stackoverflow and I was surprised how fast had you reacted.

Huge application + manipulating collections -> garbage collector kicks in?
Some related reading here at SO:
side effect for increasing maxpermsize and max heap size
And Oracle article about GC tuning:
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

It may be because of waiting (due to some heavy processing) in Event dispatcher thread in swing where events are executed. Ideally you should execute any resource intensive task in a separate thread so that UI doesn't freeze

You might already know this, but just for the sake of it i would say that if you have not used a Swing worker in your long running processes within your app, this would be a ideal situation to use it.

Diagnosing why two Java Threads hanging

Trying to make sense of my application hanging, it was all running fine then hung.
I then attached Yourkit Profiler which highlighted two threads that had not changed for some time and appeared to have hang.
The interesting thing is both threads were performing the same task but on different data, however the method is simply a cpu intensive task which isn't sharing data, performing I/O or connecting to anything else.
public int[][] computeAssignments(float[][] matrix)
So with this in mind I cannot understand what could be causing them to just stop
Both threads are run as part of an an ExecutorService
What approach should I take to resolve this.
Update
As Glen guessed the problem turned out to be completely unrelated to threads. It is just that they both happened to hit the same problem, the code they were calling could go into a recursive loop if a particular set of data was provided. A good hint another poster gave was to check in profiler whether the threads were in Runnable or Waiting state, only if they were in waiting state would they actually be deadlocked.

My guess would be that you have an infinite loop there.

Multi-Threading in Perl vs Java

I am new to Perl and I am writing a program that requires the use of threading. I have found the threads feature in Perl, but I find that I am still a bit confused. As stated in the title of this post Java is probably the most common to use threads. I am not saying that it is perfect, but I can get the job done using the Thread class.
In Java I have a method called startThreads and in that method I created the threads and then started them. After starting them there is a while loop that is checking if the treads are done. If all the threads have exited properly then the while loop exits, but if not then the while loop is watching what threads have timed out and then safely interrupts those threads and sets their shutdown flags to true.
The problem:
In Perl I want to use the same algorithm that I have stated above, but of course there are differences in Perl and I am new to Perl. Is it possible to have the while loop running while the other threads are running? How is it done?

You can implement your while loop in Perl using threads->list() but you should consider a different approach, first.
Instead of waiting for threads, how about waiting for results?
The basic idea here is that you have code which takes work units from a queue and which puts the results of the work units (either objects or exceptions) into a output queue.
Start a couple of threads that wait for work units in the input queue. when one show up, run the work unit and put the result in the output queue.
In your main code, you just need to put all the N work units into the input queue (make sure it's large enough). After that, you can wait for N outputs in the output queue and you're done without needing to worry about threads, joins and exceptions.
[EDIT] All your questions should be answered in http://perldoc.perl.org/perlthrtut.html

Be careful when using threads in perl. There are a lot of nuances about safely accessing shared data. Because most Perl code does not do threading, very few modules are thread-safe.

After reading the link that Michael Slade provided, I found that Cyber-Guard Enterprise was correct. By detaching the thread the main still is performing work. I haven't tested it out yet, but it looks like $thr->is_running() can tell me if the thread is still running.
This was taken from the url that was provided and shows how detach is used.
perldoc.perl.org/perlthrtut.html?
use threads;
my $thr = threads->create(\&sub1); # Spawn the thread
$thr->detach(); # Now we officially don't care any more
sleep(15); # Let thread run for awhile
sub sub1 {
$a = 0;
while (1) {
$a++;
print("\$a is $a\n");
sleep(1);
}
}

Analysing a multi-threaded Java application

In an open source application I'm participating, we've got a bug, where the application doesn't always close properly. That's what I'd like to solve.
Experience has shown that this happens most of the time when threads and processes are being started, but not managed correctly (e.g. a thread is waiting on a socket connection, the application is being shut down and the thread keeps on waiting).
With this in mind I've searched for '.start()' in the entire source and found 53 occurrences (which scared me a bit).
As a first step, I wanted to create a helper class (ThreadExecutor) where the current code 'thread.start()' would be replaced by 'ThreadExecutor.Execute(thread)' to have a) only a few changes in the existing source and b) a single class where I can easily check which threads don't end as they should. To do this I wanted to
add the thread to be executed to a list called activeThreads when calling the Execute method
start the thread
remove it from the activeThreads list when it ends.
This way I'd have an up to date list of all executing threads and when the app hangs on shutdown I could see in there which thread(s) is(are) causing it.
Questions:
What do you think about the concept? I'm usually coding c# and know how I'd do it using .NET with workers, but am not too sure what's best in Java (I'd like to modify as few lines of code as possible in the existing source).
If the concept seems ok, how can I get notified of a thread terminating. I'd like to avoid having an additional thread checking every once in a while what the state of all threads contained in activeThreads is, to remove them if they terminated.
Just to clarify: Before figuring out how to terminate the application properly, what I'm asking here is what's the best/easiest way to find which threads are at cause for certain test cases which are pretty hard to reproduce.

I would attempt to analyze your application's behavior before changing any code. Code changes can introduce new problems - not what you want to do if you're trying to solve problems.
The easiest way to introspect the state of your application with regard to which threads are currently running is to obtain a thread dump. You said that your problem is that the application hangs on shutdown. This is the perfect scenario to apply a thread dump. You'll be able to see which threads are blocked.
You can read more about thread dumps here.

Try to make all threads daemon(when all remaining threads are daemon the JVM terminates). Use thread.setDaemon(true) before starting each thread.

You could try to look into your application using jvisualvm (which is shipped with the jdk, find it in the bin folder of your jdk). JVisualVM can connect to your application and display a lot of interesting information, including which processes are still running. I'd give that a shot before starting down the road you describe.
Here is some documentation on JVisualVM should you need it.

The best way in java is to use Thread pools instead of Threads directly (although using threads directly is accepted). Thread pools accept Runnable objects, which you can see as Tasks. The idea is that most threads would do a small task and then end, because making a Thread is expensive and harder to manager you can use the threadpool, which allows things like 'ThreadPoolExecutor.awaitTermination()`. If you have more tasks than Threads in the pool, remaining tasks will just be queued.
Changing a Thread into a Runnable is easy, and you can even execute a runnable on a Thread you make yourself.
Note that this might not work for threads that run a long time, but your question seems to suggest that they will eventually finish.
As for your second question, the best way to find out which threads are running at a certain point is to run the application in a debugger (such as Eclipse) and pause all threads on a breakpoint in the close function.

I would try the trial edition of jprofiler or something similar, which gives you a lot of insight into what your application and its threads actually do.
Don't change the code yet, but try to reproduce and understand when this happens.

Create yourself a static thread pool.
static ExecutorService threads = Executors.newCachedThreadPool();
For every start of thread change:
new Thread(new AThread()).start();
to
threads.submit(new AThread ());
When your code exits, list all running threads with:
List<Runnable> runningThreads = threads.shutdownNow();
for ( Runnable t : runningThreads ) {
System.out.println("Thread running at shutdown: "+t.toString());
}
This will not only shut down all running threads, it will list them out for you to see what their issue is.
EDIT: Added
If you want to keep track of all running threads use:
Future f = threads.submit(new AThread ());
and store it in a list somewhere. You can then find out about its state with calls like:
f.isDone();
... etc.

Thread vanishes without a trace

I'm trying to debug an issue. We have few Threads that work on data from a BoundedLinkedQueue. After processing one record, the current thread executes Thread.currentThread().yield().
Now, once a while it is observed that one of the thread just vanishes ! I have traced the logs to find that such a "vanishing" thread works till the yield statement. After that no traces of that thread are found - nor any errors or exceptions are thrown near the last log seen for the thread.
Can anyone give any pointers for debugging directions ? Is the usage of the yield correct ? Is the yield a reliable statement ? This is because I found out this article suggesting to avoid the yield statement ? Has anyone seen such a condition before ?
Edit: On some research, it seems that try/catch may miss some exceptions and those would be just put into System.err which may not be noticeable in a multi-threaded environment. Thanks to #JVerstry for the pointer, I have set uncaughtexceptionhandler for the Thread. The build and run process takes long. Will update more once I have something concrete.
Here are few links that talk about UncaughtExceptionHandler:
Thread.UncaughtExceptionHandler
Catching Uncaught Exceptions in JDK 1.5
Java theory and practice: Hey, where'd my thread go ?
Know the JVM Series 1 - The Uncaught Exception Handler

As pointed out in the article you linked, yield doesn't define whether or not the current quantum is interrupted. If you yield right before thread exit, the scheduler just might complete the quantum for the thread causing the thread to exit immediately.

Yield does not make threads vanish. It is possible that your thread throws an exception and that is not caught. Did you implement an uncaught exception handler? If not, then I recommend you do so. It would explain your problem (unless the thread ends up naturally and your code does not do what you think it should do).

What occurs after the yield? Will the thread exit or will it attempt to process another piece of data from the queue?
You should verify that the what is being called after the yield is actually being called with logging.
How do you know the thread has exited? Have you verified by using by looking at a stack trace (Use Jstack)?
Lastly why are you using yield at all? I assume your BoundedLinkedQueue allows threads to retrieve data in a thread-safe manner, or blocks if the queue is empty. Why not just let the JVM manange thread scheduling?

We were able to get a thread dump when this re-occurred and seems that the thread was just blocking on a JDBC call forever - a bug in the jdbc jar. We just replaced the jar with the latest version and seems to have solved it. Thanks all for the valuable inputs - made me learn a lot of new things. Also, now put a query time out to prevent blocking forever.