Click here to Skip to main content
15,916,180 members
Please Sign up or sign in to vote.
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;

    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 = null; 

.. 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.
Updated 5-Sep-22 5:41am

1 solution

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.
Share this answer
ThePotty1 5-Sep-22 17:16pm    
Bahaha I resemble that remark :p

Yeah It occurred to me that I'm just calling a function, which is something we do a lot, in the happy and certain knowlege that the function will run through it's logic, and then return. I got distracted by the weird wrappers, but until the function returns, the calling code just waits.

EDIT 100 threads? Wow, no, well thread count is set in xml, but currently I'm running on 3.

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

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900