Modifying a static class so I can call it from multiple threads simultaneously

Question

0.00/5 (No votes)

See more:

So, I have a set of just over 100 classes which I call from a Runnable class, If I call all different classes it works fine.

public class RunnableTask implements Runnable
{
    private long wb_id;
    private int job_id;
    
    public RunnableTask(long wbId, int jobId)
    {
    	this.wb_id = wbId;
    	this.job_id = jobId;
    }

    @Override
    public void run() 
    {
		switch (this.job_id)
		{
			case 1010:		id1010.start(wb_id);	break;

However, it is very possible that I will receive multiple tasks of the same job, which I assume will not work at all, because the classes are currently static?

What I have tried:

So now I'm looking at:

case 1010:
{
 id1500 job1500 = new id1500();
 job1500.start(wb_id);
 //job1500 = null; 
 break;
}

.. and a warning: Resource leak: 'job1500' is never closed.

My question is, does java sit on the .start line until the class finishes, in which case I can destroy the class? Or does it fire the start and continue? What would happen if I put this in a try block? I would put some logging in and see what order everything comes out, but right now hardly anything in the system doesn't have some sort of error, or needs to be pointed to the new jar, basically I need to know whether to roll back or continue into the sunset. Although the only way I'm rolling back is if everything is on fire.

Posted 5-Sep-22 5:02am

ThePotty1

Updated 5-Sep-22 5:41am

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2022-09-05T05:41:00

I get the strong impression that you don't know what you are doing, and when you start playing with threads that's a very bad idea. Not only can you make your app slower and consume significantly more memory by threading if you aren't careful, you can also add intermittent bugs and data corruptions which are pretty much impossible to sort out.

I'd really recommend that you start by reading up on static vs instantiated classes: What is a static class in Java?[^] and Static methods vs Instance methods in Java - GeeksforGeeks[^]
Them move on to threading and locking: Java 8 Concurrency Tutorial: Threads and Executors - winterbe[^] and try some simple apps to get a good feel for the whole concept before you start using is in anger - there is an awful amount you can get wrong very, very easily and a small app is a lot easier to work out what is going wrong that a big complicated one. You can then use that knowledge and experience to get it working in your "real" project.

But do bear in mind that threading is not a magic bullet: each thread needs time on a core to execute: so if you have N cores and N * 2 threads, half of them at least will not be executing at any given moment because they are waiting for a free core. Since each thread adds it's own overhead in terms of both memory and processing to switch threads, (and locking increases that overhead) if you blindly add 100 threads to your app, you're going to degrade performance quite significantly.