Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I have a GUI application on windows 7 64 bit (service pack 1)
My GUI application has some Java in it and it dispatches Delphi code -
Lately, after upgrading to a multicore PC - we've noticed that some heavy GUI actions cause the GUI to get stuck. We only have one thread that updates our GUI.
After debugging it, we noticed that once in a while, a call made by delphi to win api's "SendMessage" just waits for ever.
We then tried to set the program's affinity to 1 - and the problem was solved, but it slows down our application.
I know that it is common to replace SendMessage with PostMessage or SendMessageTimeout, but there are many places where we use SendMessage + we also use DevExpress components that also use SendMessage - we can't possibly map all these places.
What seems most bizarre is that even though our GUI has one thread, set affinity to 1 solves the problem (there are other background threads in the system, but they are all pure java and perform some data calculations).
my questions are:
Any known ways to fix this problem? Maybe known bugs in Windows 7?
Is it possible that the messages I sent is somehow lost? Is there a limit to the total messages or rate? If so, how can I increase these limits?
How can I get more information - for example: check somewhere in windows what happened to my message - where/why did windows get stuck etc.
Any way of further analyzing the problem will be greatly appreciated.
Thank you very much
SendMessage() relies on the target window's message queue when sending a message across thread boundaries. This is documented behavior:
http://msdn.microsoft.com/en-us/library/ms644950.aspx
If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message.
Thus, SendMessage() will not exit until the target thread has retrieved the message from its message queue and then either processes the message in full or calls ReplyMessage() to release SendMessage() while continuing to process the message.
So, if SendMessage() is getting stuck, it means the target thread is not processing its message queue, which is a good indication that the target thread is likely deadlocked waiting on something else.
The fact that your app runs fine when locked down to 1 CPU core but has problems when allowed to run on multiple CPU cores means your app is likely not performing inter-thread synchronizations in a multi-core safe manner. In a single-core system, only one thread can physically run at any given moment. Because of the way the OS uses thread scheduling and task switches to handle concurrency, unsafe syncs may be "safe enough" in some cases. But multiple cores can truly run in parallel, so it is possible for threads running on different cores to access memory/resources at the exact same moment, so it is very important that inter-thread syncs are done correctly to make sure that is not allowed to happen, otherwise your app can get out of sync with itself, and all kinds of bad things can happen (case in point - your deadlock).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I don't have an error or crashes but i always see this message on my log on my android studio "The application may be doing too much work on its main thread.". Can someone enlighten me with log message. Maybe i am doing something wrong on my coding or should i just don't mind this?
In a way, this could be the answer to your question as well
First off, you need to be aware of 2 concepts:
Synchronous : will run in the same thread.
Asynchronous: will run in a different thread.
There's a few things possible here, one of them is that using the app in debug mode / running with debug build variant contains plenty of logs and slows down the app, which can cause this message - while actual users never see an issue with this since those logs are automatically removed(and you should clean up your personal logs before release as well).
Another one - usually when you're new to android development you write all the code on the main thread, which works fine up to some limit, but when you start implementing complex operations in the app(e.g. loading large images/files, downloading images/data synchronously - but mind you, this is usually asynchronous when you're using a popular library for networking/image loading normally, you can use them synchronously when needed though as well) this can become a problem. This usually happens as you build up on your app.
By default, everything you write in the code is being run on the UI thread(synchronously). This causes android to render UI updates and code operations simultaneously. The proper way of doing things in android is that you do all the complex operations asynchronously, and only when all those operations are completed, you update the UI on the main thread with completed data.
( Because the screen is refreshed every 16 ms (1 s/60 fps = 16 ms per
frame), it is crucial to ensure that all of your rendering can occur
in less than 16 ms.)
If the rendering takes longer than 16ms, that message pops up at times.
It's a bit hard to follow this rule at all times, but with some practice comes perfection, and when doing it like this, end-users will pretty much never experience stuff like ANR's or UI freezes.
Of course, it's not all sunshine and rainbows, doing things asynchronously brings its own set of problems. If you're not familiar with these concepts, you should read up on synchronous/asynchronous, threading, and kotlin coroutines. Lifecycles(activity/fragment/in general) and Support different screen sizes could be helpful as well
It's just a simple message indicating that your app code taking long to process and it's skipping frames due to that. It happens most of the time as there is always something in the normal code that's not utilized well for the RAM & CPU.
But it should not be a problem if the the number of frames skipped are fairly small (<100). But if the number of frames skipped and large and in the order of 300+ then there can be some serious trouble with your code.
So try utilizing tasks which are being done on the main thread. Perform data loading & other background tasks on the background task & UI related tasks on the Main thread.
I have a JavaFX 8 app that is occasionally hanging/freezing. I feel I've ruled out many causes of the problem, but it's still happening.
Unfortunately I cannot reproduce the freeze/hang on demand. It actually only happens (so far) on my colleague's computer. It can happen not long after the App has been running, or it may happen after many hours, or it may not happen at all. It does not happen after any user initiated event (such as pressing a button).
I have a few background threads running that read data from sockets and update the JavaFX UI. These updates are always done via the Platform.runLater() method.
The background threads may read many hundreds of data updates per second, so I have applied throttling to prevent too many updates on the UI, as suggested here: Throttling javafx gui updates
The user can initiate some long(ish) tasks, which are run on the JavaFX UI thread, or using the Task method. I know and expect the JavaFX UI to block/freeze when calling a method with long execution time on the JavaFX UI thread. But such calls are only made by the user pressing a button and as stated above, the freeze occurs without the user interacting the the App in any way.
I have caught the freezing (twice) on my colleagues computer and inspected the process in JConsole and VisualVM. The thread dump showed no deadlocks. When I compare the thread dump with a non-frozen JavaFX App thread dump, there are no obvious differences.
It appears that only the JavaFX UI is frozen. The background threads continue without error.
The CPU is not high and the computer is not running slow when the freeze occurs.
My App code consists of many classes, so it's not straight forward to include it here, especially as I don't know which method causes to freeze. And therefore my question is rather broader than I would like:
Given the assertions above, do you have any suggestions as to what
might be a cause of such an error?
Given the assertions above, do
you have any suggestions as to what might be another way to trace
such an error?
Thanks to John16384 and Mipa for their replies...
I use the javafx-maven-plugin Maven plugin, so the JavaVM arguments by including:
<jvmArgs>
<jvmArg>-Dprism.verbose=true</jvmArg>
<jvmArg>-Dprism.order=sw</jvmArg>
</jvmArgs>
in my plugin configuration. Since including this, we haven't had the freeze for a couple of days. I'm hoping this is the final fix!
Have you tried AOP ?
Aspect Orientated programming
It in your case would allow you to run a method before and after every method you use, if you logged something if these times were greater than a certain time, then you could determine which bit of code was causing it e.g. log if the time inside a method is greater than 5 seconds
See here for a tutorial to just that
I am developing a software with java, it creates a thread upon receiving an event (from sensors). the time-to-live of these threads is very small (< 1 second)
The sensor sends maximal 10 events/minute.
This app works fine for most of the time. but sometime it hangs.
When looking at the eclipse debugger, I find out that there are to many threads and most of them are "Thread[garbage collected]" (about 800 threads #_#)
I don't know if that bug is caused by dynamic-creating-threads in my code or other bugs?
EDIT:
The problem is indeed caused by creating too many threads. I have logged all sensor's events with timestamp and there are some points it creates about 1200 events/minute (damn!).
I also wrote a small java program which creates as many threads as posible. At ~4100th thread (well, wooden computer) , jvm crashes. It does not hangs like my app does :-?.
Therefore I suppose that there are (maybe) rare conditions while creating threads dynamically and it causes the garbage collection threads hang?
Don't create a new thread for each event that is received. Instead, use the classes from the java.util.concurrent package.
Create an ExecutorService (using one of the static methods in class Executors) and submit jobs for handling events to the ExecutorService. The ExecutorService is a thread pool that manages the threads for you.
I had a similar problem in NetBeans. After a while, the program would hang with lots (maybe 500) of suspended threads. However, when run outside the debugger it worked just fine. I don't think I ever got more than a couple hundred threads going at once running when running outside, but the program did tend to start them at a furious rate. My suspicion was that the debugger never shut down a thread and could only handle so many.
My experience so far is that the JVM handles vast numbers of rapidly starting and stopping threads very well, but that the NetBeans debugger (several versions ago now, one of the 6's) did not.
This question already has answers here:
How many threads can a Java VM support?
(13 answers)
Closed 9 years ago.
we are developing a game using Java as a server side programming. and i have no knowledge on Java to be honest.
We are using 7-10 threads, for a table and there are 80-100 tables max, this is coming upto 1000 threads running backend.
How bad it is, will this screw up the application on a longer run ??
Thanks for your inputs
Thanks,
Satish.
Check this answer. It'll explain most of the things:
How many threads can a Java VM support?
Also consider redesigning your application.
My first thought is: don't do this. If you have an application that requires multiple threads then that's fine. However consider that your computer's underlying architecture (processor) can only run so many threads at a time. The Operating System (OS) simulates multi-tasking by constantly switching which thread is executing at any given time. For example, if you have a simple single core processor, only one thread can be run on it at a time, so the OS will have to swap the currently executing thread if there is more than one. Of course, this over simplifies things and ignores all the other applications running on your computer, but that's the general idea of things.
If you have lots of tasks that can be threaded, consider using a thread pool (or using a library to do it for you) where you have a set number of threads that will run tasks from a queue.
Don't do this. Threads need to be owned by a process, not an entity like a Table. Used a ThreadPool, often ScheduledThreadPoolExecutor tends to work for most cases, and tables should request access to this resource.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java thread affinity
I have a server and it has a 16 cores cpu.
In Java, I need to create some threads (the number of threads is less than 16). Each thread needs to run some operations, e.g., process an event queue.
How can I create these threads so that it guarantees that each thread is assigned to one core forever? I mean I don't want the OS exchanging cores for one thread. I just wish one thread is dedicatedly running on a fixed core.
Can I do that?
The reason I want this is
I handle some background tasks (computation intensive) and some user-facing tasks in the same server. I don't want the user side get any negative impact. For example, if my computation tasks are assigned to 16 cores, surely the threads which are running for user side will be negatively affected, right?
You cant. JVM virtualizes all hardware so you can not do anything like that.
There could be some 'tricks' that would work on some specific architecture and some specific JVM, but it would all be hackish and unreliable.
Don't waste your valuable development time on this. Fix some other problems. If the time taken by OS core menagement is an issue for your app, it's teetering on the edge of failure anyway.
no you cannot do that since the OS Scheduler is meant to assign threads to cores. The JVM in which your java app runs does not have access to it.
You shouldn't.
If you really want to, you can use native calls : Java thread affinity
But really, be sure to have a good reason to do this. Why do you think that's a good idea ?