1

The first way is this:

public class Demo {
    public static void main (String args[]) {
        Apple a1 = new Apple();
        Apple a2 = new Apple();
        Thread t1 = new Thread(a1, "First Thread");
        Thread t2 = new Thread(a2, "Second Thread");

        t1.start();
        t2.start();
    }
}

The second way is this:

public class Demo {
    public static void main (String args[]) {
        Apple a = new Apple();
        Thread t1 = new Thread(a, "First Thread");
        Thread t2 = new Thread(a, "Second Thread");

        t1.start();
        t2.start();
    }
}

The void run() method is in Apple class and I did not paste it here. Seems like in the first situation I created 2 Apple class objects and pass them respectively to t1 and t2. While in the 2nd situation I pass the same Apple class object to t1 and t2. What's the real difference in terms of multi-threading? Could you suggest me which way is correct and recommended? Thank you!

Michael
  • 41,989
  • 11
  • 82
  • 128
Mr.Snail
  • 51
  • 7
  • Sorry spare my poor format editting here.... The page confuses me... – Mr.Snail Jun 06 '18 at 14:57
  • When writing your post, have a look at the preview that can be found just below the text box. That way, you can see if the formatting has worked correctly. – jsheeran Jun 06 '18 at 14:57
  • Doing it the first way solves one class of problem. Doing it the second way solves a different class of problem. What is the problem that you want to solve? – Solomon Slow Jun 06 '18 at 17:16

4 Answers4

1

If your Apple object is stateless then there is no difference. But if it has some state and its run() method modifies it properties then you need to synchronize access to those properties (or make sure that those properties are thread-safe) of an Apple object.

What to prefer depends on your business logic.

Ivan
  • 8,508
  • 2
  • 19
  • 30
1

If Apple is an object which is thread-safe then it may be okay (or indeed desirable) to share it between threads. If it's not thread-safe then by using it concurrently you are creating an opportunity for race conditions and other difficult-to-diagnose bugs to occur.

Michael
  • 41,989
  • 11
  • 82
  • 128
0

Difference depends a lot on implementation of Apple class, in 1 case this might be best option while in another it might be huge mistake.

If class Apple is immutable and just exposes some data or event better if it only has pure functions which depend only on their input parameters then using same instance is desired approach.

On the other hand if class isn't made to work with multiple threads then you will definitely run into race condition problems.

FilipRistic
  • 2,661
  • 4
  • 22
  • 31
0

It really depends on what the Apple class really does. Let's look at a sample Apple class:

public class Apple implements Runnable{
    private int counter;

    @Override
    public void run(){
       for(int i = 0; i < 10; i++){
           counter += i;
       }
       System.out.println(counter);
    }
}

Now in the first way you get prints in the console which look like the following:

45 // first thread
45 // second thread

Though in the second way it will be pretty unpredictable because now both Threads are modifying the counter variable. It could at best look like this:

45 // first thread 
90 // second thread

But could also look like this:

51 // first thread
90 // second thread

In this simple example it is not a big issue. But when handling other tasks, which maybe modify files, accesses databases or anything that relies on deterministic behavior you'll get into big trouble.,

Lino
  • 19,604
  • 6
  • 47
  • 65