Develop Reference

JavaFX GUI thread and locked screen on Windows

I have my JavaFx application that reads data from API on background thread ( or for testing it is preloaded from local storage on application start ) and then it processes and sets data to model that is directly binded on properties in my view. Because processing and setting data to model changes text shown in components, it is called with Platform.runLater(). Normally when it is called it consumes around 2% of CPU, but if i run application for longer time, consumption of CPU on data processing goes higher a little bit(probably data processing is too much for GUI thread). It gets for example around +4% in 1 hour.
However what I see as strange behaviour is that when i lock my Windows and go away for few minutes and then come back, CPU usage on data processing changes from 8% to 17% for example and then stays that high. Does it mean that when Windows screen is locked then GUI thread doesn't run? It seems to me like not and then when it unlocks, GUI thread gets overwhelmed byPlatform.runLater() calls. But when it is not processing data, it consumes 0% of CPU, so i'm really confused.
Does anyone know what could cause this? Does GUI thread really stops working when windows are locked?
EDIT:
I've already found that processing received data is probably too intensive task for UI thread and I'm trying to optimize it (do most of processing on background thread and then just call setting data with Platform.runLater.
Code for background download is really simple PoF at this moment and looks like this:
Thread updateDaemon = new Thread(() -> {
try {
while (true) {
TimeUnit.SECONDS.sleep(5);
processMarketStateData(view.getTable(), data);
}
}
}
catch (InterruptedException e) {
logger.error("Background worker interrupted", e);
}
});
updateDaemon.setDaemon(true);
updateDaemon.start();
In processMarketStateData i do some processing and then set data to model on UI thread. But what i'm actually curious about is that strange CPU usage behaviour. When update thread is sleeping and i do not interact with UI then CPU usage is 0%. When processMarketStateData it takes few % of CPU and then it is again 0% till update thread ends its sleep. But for some strange reason after several processMarketStateData calls CPU usage goes up more and more. I goes up by small percentage, like 1% after 50 calls, maybe more. Even weirder is it takes way less calls to produce this strange behaviour when windows screen is locked. When it goes really insane and it takes already around 20% of CPU for call, it goes that high only on processMarketStateData call, for rest of the time it is 0%. After really long ( few hours ) test i ended up in state where application took 25% of CPU permanently and UI was inresponsive. Note that there are 2 these threads running at same time.
My actual question is not "why my ui lags when i process data", that was not hard to find, but it is "why it acts the way it does?"
I hope this edit made my question better.
EDIT2: Another strange behaviour as well is that if I leave application minimalized for a while with auto updating and open it then, it is black window for a while, but application that doesn't have auto update is ok. This really makes me think that javaFX UI thread doesn't run when application is minimalized or windows screen is locked. Sadly i could not find much about this.

probly these links may help you
Execute task in background in JavaFX
https://docs.oracle.com/javase/8/javafx/interoperability-tutorial/concurrency.htm
https://docs.oracle.com/javafx/2/threads/jfxpub-threads.htm
This may be you are doing a cpu intensive task in UI thread . please provide some code samples.
you can use a service class to do the cpu intensive calculation and then update the ui in the plateform.runlater call.

It seems that I've found the real issue and fixed it. Unfortunately unless I would share my whole project, you would not be able to help me. Problem was that there was method called from processMarketStateData method that sets style depending on data received. Problem was that it called node.getStyleClass().add(style) without checking presence of style. So after 15 minutes size of node.getStyleClass() was around 300. After adding that check it seems that everything runs ok and it takes max 2% of CPU.

javaw.exe high cpu usage

I have created a runnable jar, which runs on a single thread. The thread executes a for loop having 100 iteration. However the cpu usgae goes upto 60% on i3 processor win7 64 bit machine.
I tried to analyze the cpu usage in process Explorer
The native threads are consuming CPUs.
The native threads are all at msvcr100.dll!endthreadex+0x60
consuming cpu
I am using jdl 1.7.
Can somebody please suggest what might be going wrong here.
Here is the code:
the app accepts socket connection and processes the date sent by the client.
while (true)
{
try
{
Socket sock = ssock.accept();
// This is the function which has the for loop
obj.MyFunction();
}
catch(Exception ex)
{
ssock.close();
}
Thread.sleep(1000);
}
void MyFunction()
{
for(int i=0; i < 1000;i++)
{
// Processing done here
}
}

Profile your code, see http://docs.oracle.com/javase/7/docs/technotes/tools/index.html#jconsole for more info.

I suspect that if you try this:
ex.printStackTrace();
you might get some more information. Right now, when you get an exception, you have no idea what happened or why. You are silent about it, which is rarely the right behavior for hitting exceptions.
What is the processing? If you're trying to do a lot of work, it might not be unexpected to go to 60% cpu. What's the Big O runtime of your algo? What's the data set size?

Java SWT GUI Becomes Unresponsive to Updates During Long Running Background Process

Technologies Used:
Java 1.6
SWT GUI
Problem:
GUI information updates eventually stall (GUI becomes completely unresponsive) after approximately 60 minutes of a background task running.
The problem appears to be with the GUI updates, and I cannot figure out how to remedy this situation (reviewed the Java concurrency options, etc.). The Optimization thread periodically updates the text box in the GUI with processing information. During my testing, this "update" lags SIGNIFICANTLY behind the console output and database output--by that, assume the optimization performs 4000 optimization steps. The console may report working on optimization step 1900 (confirmed in the database) but the GUI stills outputs information from step 700.
Background Info:
I am running a machine learning optimization task and incorporate the task into an SWT GUI. The task may take an hour or more to run to completion depending on parameters. I designed the optimization task as a separate thread. The GUI allows the user to press a button to launch the optimization. The GUI includes (to simplify) 1) a table of tasks and 2) a SWT text box for feedback during the optimization. The table of tasks gets updated as each distinct task group is completed. The SWT text box outputs more regular/frequent feedback (much like System.out BUT using threading to update the text box via the GUI EDI thread). That is, I believe I am using at least three threads: 1) the GUI thread, 2) the aSync thread for GUI updates (SWT), and 3) a background thread for the optimization itself. (I mention this because the Java concurrency tutorials expressly direct that long running tasks must run in their own thread to avoid GUI deadlock and starvation. However, even though I think I did this, the GUI still stalls after a long optimization run--and this is what I am trying to fix. Because the optimization runs take so long to complete, the GUI stall is a major issue--losing more than an hour before realizing the GUI stalled.)
Basic Program Structure:
GUI Class-->launches a separate thread for the Optimization Class
Optimization Class can update GUI class components (using SWT asyncExec) via call-backs
Confirmed:
I can confirm that the background thread runs fully--1) the background thread updates several database tables and all tables are fully and completely updated; 2) System.out output directly from the optimization task sent to console in Eclipse shows the optimization thread runs fully and completely.
Furthermore, during testing, if I scale back the optimization set to perhaps 400 steps, the GUI seems to run fine.
Relevant Code:
GUI CLASS--
Code to Update GUI and in GUI Class (this gets called by the Optimization Class Thread)--
public void setFeedback(final String workerthreadinfo, final boolean append) {
try{
Display.getDefault().asyncExec(new Runnable(){
public void run(){
if(!textfeedback.isDisposed() && textfeedback !=null){
if (append) {
textfeedback.setText(workerthreadinfo + "\n" +
textfeedback.getText()) ;
} else {
textfeedback.setText(workerthreadinfo) ;
}
}
}
});
} .....
Instantiation of the Optimization Worker Thread in GUI Class
private OptimizerWorkerThread workerthread =
new OptimizerWorkerThread(this) ;
Code in GUI Class Launching the Optimization Class (as thread)
protected void optimize() {
workerthread.go() ;
}
OPTIMIZATION CLASS--
Optimization Thread Method "linking" to the GUI (guiwindow = GUI class above)
// ==================================================================
// GUI Update Methods
// ==================================================================
public void updateFeedBackInfo(String update, boolean append) {
guiwindow.setFeedback(update, append) ;
}
Example of Call Back to GUI from the Optimization Thread
//GUI Feedback
this.updateFeedBackInfo("Saving optimization run record to database ... ",
APPENDTEXT ) ; // APPENDTEXT = boolean TRUE instructing GUI textbox to append

This does not sound so much like a threading issue.
If you would run by accident in the GUI thread, the GUI would be dead right after clicking the button. So I think we can rule that out.
What you describe sounds more like a memory load / performance issue. I strongly recommend connecting Visualvm with your application and look especially for constantly increasing memory consumption. Also using the profiler included in visualvm might hint at stuff that is consuming lots of cpu or memory.

Solution Addendum:
During final testing of this application, I more carefully identified the apparent source of the GUI slow down. By GUI slow-down, I mean the difference between copying 2500 files. The slow-down problem required almost 20 minutes to complete the copy. With the fix applied, the exact same files took less than 1 minute to copy.
The Problem
The copy is handled through a Worker Thread. The worker thread periodically updates the GUI. The update includes a ProgressBar update and a text box update.
The text box update appears to be the source of the problem. What I wanted was a text box the PREPENDS the status update information--such as "Copying File C:/hello.txt"--rather than append (available in SWT). To create a faux prepend I used (in a separate thread):
textfeedback.setText(workerthreadinfo + "\n" + textfeedback.getText()) ;
This little piece of code appears to be the slow-down culprit--and probably is easy to see why. On every file copy, the entire text box contents are copied then the new information is prepended to the text box. After copying about 700 files, this starts to bog down (you can see the slow-down visibly) and continues to deteriorate afterwards.
The fix, although I am not happy with it, is to use the SWT TextBox append() method instead.

why my android project raise CPU usage range from 60% ~ 100%?

Hello I'm making a chat application in android
so overall, I have a service which contains lots of classes and threads.
in my service, i had socket input read class, socket output writer class, and pinger that in summary have 6 threads.
Actually, i'm very new with this problem, well i can say i have no idea what makes a program occupy high percentage of CPU processes. is it cause too many static variables maybe? or too many running threads maybe, or too many local variables maybe?
I don't know exactly what is going on...?
So, please share with me your experiences and knowledge
UPDATE
public void run() {
while(isRunning) {
try {
Thread.sleep(500);
if(!startCheck) {
//Log.v(TAG, "SocketQueue: "+socketTaskQueue.size()
if(socketTaskQueue.size() > 0) {
processSocketTask();// TODO
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
so basically, i made my threads like above example.
so, i have a vector called socketTaskQueue, and this thread job's is to check whether there's a socket task or not. if it does, then it will execute processSocketTask function that will get the top element of the vector queue and then remove it.
UPDATE
T.T this post is embarrassing! i forget to put Thread.sleep() in some of my threads!
SORRY FOR BOTHERING YOU GUYS! :p

It is caused, usually, by threads that use CPU even when they cannot accomplish useful work. For example, when a thread is waiting for something to happen, does it wait in a way that uses no CPU? Or does it keep waking up needlessly even before it can do work?
It can also be caused by threads that do work in extremely inefficient ways.

Java while loop and Threads! [duplicate]

This question already has answers here:
How can I abort a running JDBC transaction?
(4 answers)
Closed 5 years ago.
I have a program that continually polls the database for change in value of some field. It runs in the background and currently uses a while(true) and a sleep() method to set the interval. I am wondering if this is a good practice? And, what could be a more efficient way to implement this? The program is meant to run at all times.
Consequently, the only way to stop the program is by issuing a kill on the process ID. The program could be in the middle of a JDBC call. How could I go about terminating it more gracefully? I understand that the best option would be to devise some kind of exit strategy by using a flag that will be periodically checked by the thread. But, I am unable to think of a way/condition of changing the value of this flag. Any ideas?

I am wondering if this is a good practice?
No. It's not good. Sometimes, it's all you've got, but it's not good.
And, what could be a more efficient way to implement this?
How do things get into the database in the first place?
The best change is to fix programs that insert/update the database to make requests which go to the database and to your program. A JMS topic is good for this kind of thing.
The next best change is to add a trigger to the database to enqueue each insert/update event into a queue. The queue could feed a JMS topic (or queue) for processing by your program.
The fall-back plan is your polling loop.
Your polling loop, however, should not trivially do work. It should drop a message into a queue for some other JDBC process to work on. A termination request is another message that can be dropped into the JMS queue. When your program gets the termination message, it absolutely must be finished with the prior JDBC request and can stop gracefully.
Before doing any of this, look at ESB solutions. Sun's JCAPS or TIBCO already have this. An open source ESB like Mulesource or Jitterbit may already have this functionality already built and tested.

This is really too big an issue to answer completely in this format. Do yourself a favour and go buy Java Concurrency in Practice. There is no better resource for concurrency on the Java 5+ platform out there. There are whole chapters devoted to this subject.
On the subject of killing your process during a JDBC call, that should be fine. I believe there are issues with interrupting a JDBC call (in that you can't?) but that's a different issue.

As others have said, the fact that you have to poll is probably indicative of a deeper problem with the design of your system... but sometimes that's the way it goes, so...
If you'd like to handle "killing" the process a little more gracefully, you could install a shutdown hook which is called when you hit Ctrl+C:
volatile boolean stop = false;
Runtime.getRuntime().addShutdownHook(new Thread("shutdown thread") {
public void run() {
stop = true;
}
});
then periodically check the stop variable.
A more elegant solution is to wait on an event:
boolean stop = false;
final Object event = new Object();
Runtime.getRuntime().addShutdownHook(new Thread("shutdown thread") {
public void run() {
synchronized(event) {
stop = true;
event.notifyAll();
}
}
});
// ... and in your polling loop ...
synchronized(event) {
while(!stop) {
// ... do JDBC access ...
try {
// Wait 30 seconds, but break out as soon as the event is fired.
event.wait(30000);
}
catch(InterruptedException e) {
// Log a message and exit. Never ignore interrupted exception.
break;
}
}
}
Or something like that.

Note that a Timer (or similar) would be better in that you could at least reuse it and let it do with all of the details of sleeping, scheduling, exception handling, etc...
There are many reasons your app could die. Don't focus on just the one.
If it's even theoretically possible for your JDBC work to leave things in a half-correct state, then you have a bug you should fix. All of your DB work should be in a transaction. It should go or not go.

This is Java. Move your processing to a second thread. Now you can
Read from stdin in a loop. If someone types "QUIT", set the while flag to false and exit.
Create a AWT or Swing frame with a STOP button.
Pretend you are a Unix daemon and create a server socket. Wait for someone to open the socket and send "QUIT". (This has the added bonus that you can change the sleep to a select with timeout.)
There must be hundreds of variants on this.

Set up a signal handler for SIGTERM that sets a flag telling your loop to exit its next time through.

Regarding the question "The program could be in the middle of a JDBC call. How could I go about terminating it more gracefully?" - see How can I abort a running jdbc transaction?
Note that using a poll with sleep() is rarely the correct solution - implemented improperly, it can end up hogging CPU resources (the JVM thread-scheduler ends up spending inordinate amount of time sleeping and waking up the thread).

I‘ve created a Service class in my current company’s utility library for these kinds of problems:
public class Service implements Runnable {
private boolean shouldStop = false;
public synchronized stop() {
shouldStop = true;
notify();
}
private synchronized shouldStop() {
return shouldStop;
}
public void run() {
setUp();
while (!shouldStop()) {
doStuff();
sleep(60 * 1000);
}
}
private synchronized sleep(long delay) {
try {
wait(delay);
} catch (InterruptedException ie1) {
/* ignore. */
}
}
}
Of course this is far from complete but you should get the gist. This will enable you to simply call the stop() method when you want the program to stop and it will exit cleanly.

If that's your application and you can modify it, you can:
Make it read a file
Read for the value of a flag.
When you want to kill it, you just modify the file and the application will exit gracefully.
Not need to work it that harder that that.

You could make the field a compound value that includes (conceptually) a process-ID and a timestamp. [Better yet, use two or more fields.] Start a thread in the process that owns access to the field, and have it loop, sleeping and updating the timestamp. Then a polling process that is waiting to own access to the field can observe that the timestamp has not updated in some time T (which is much greater than the time of the updating loop's sleep interval) and assume that the previously-owning process has died.
But this is still prone to failure.
In other languages, I always try to use flock() calls to synchronize on a file. Not sure what the Java equivalent is. Get real concurrency if you at all possibly can.

I'm surprised nobody mentioned the interrupt mechanism implemented in Java. It's supposed to be a solution to the problem of stopping a thread. All other solutions have at least one flaw, that's why this mechanism is needed to be implemented in the Java concurrency library.
You can stop a thread by sending it an interrupt() message, but there are others ways that threads get interrupted. When this happens an InterruptedException is thrown. That's why you have to handle it when calling sleep() for example. That's where you can do cleanup and end gracefully, like closing the database connection.

Java9 has another "potential" answer to this: Thread.onSpinWait():
Indicates that the caller is momentarily unable to progress, until the occurrence of one or more actions on the part of other activities. By invoking this method within each iteration of a spin-wait loop construct, the calling thread indicates to the runtime that it is busy-waiting. The runtime may take action to improve the performance of invoking spin-wait loop constructions.
See JEP 285 for more details.

I think you should poll it with timertask instead.
My computer is running a while loop 1075566 times in 10 seconds.
Thats 107557 times in one second.
How often is it truly needed to poll it? A TimerTask runs at its fastest 1000 times in 1 second. You give it a parameter in int (miliseconds) as parameters. If you are content with that - that means you strain your cpu 108 times less with that task.
If you would be happy with polling once each second that is (108 * 1000). 108 000 times less straining. That also mean that you could check 108 000 values with the same cpu strain that you had with your one while loop - beause the you dont assign your cpu to check as often. Remember the cpu has a clock cycle. Mine is 3 600 000 000 hertz (cycles per second).
If your goal is to have it updated for a user - you can run a check each time the user logs in (or manually let him ask for an update) - that would practically not strain the cpu whatsoever.
You can also use thread.sleep(miliseconds); to lower the strain of your polling thread (as it wont be polling as often) you where doing.