Solution but I don't understand! - Java Core Level 7, Lesson 10, exercise synchronised methods

OK, here's a sample main method so that you can see how a Solution object can possibly used by threads.

Solution s = new Solution();

    Runnable r1 = new Runnable () {

        @Override
        public void run() {
            s.method1("Test");
            s.method2(3);
            double d = s.method3();
        }
    };

    Runnable r2 = new Runnable() {
        @Override
        public void run() {
            double d = s.method3();
            s.method4();
            s.method0();
        }
    };

    Thread t1 = new Thread(r1);
    Thread t2 = new Thread(r2);
    Thread t3 = new Thread(r1);
    Thread t4 = new Thread(r2);

}

You see that I have two Runnables and in total 4 threads. 2 threads always use the same Runnable and each Runnable uses the same Solution object s. Means s is used in four threads. You know that you need to synchronize methods or resources if the resource is shared or a shared resource is used in a method.

protected void method1(String param1) { // no shared resource involved
    Solution solution = new Solution();
    solution.method0();
}

If one of our threads accesses method1, then a new Solution object is created and just this new object is used. That's not a shared resource, that's a local object. No synchronization needed.

public void method2(int param1) { // no shared resource involved
    param1++;
}

Same here, an argument is passed, each thread uses it's own primitive for that, an argument is similar to a local variable. No shared resource involved -> no synchronization needed.

synchronized double method3() {
    double random = Math.random();
    param += 40.7; // shared resource modified
    return random + param;
}

all of our four threads will access here the same resource param. It's an instance variable of our s object. All runnables use s, all threads use only runnables that use s and therefore all threads use the same s.param field. So we have a shared resource here and a shared resource means synchronization needed.

private synchronized void method4() { // shared resource modified (StringBuilder not thread safe)
    sb.append(1).append(1).append(1).append(1);
}

sb is a field of the s object that's shared among our threads. s is referencing a mutable object (StringBuilder) and that object isn't already synchronized -> we need to synchronize the method or at least the part where sb is accessed. If only immutable objects would be used we won't need to synchronize (immutable objects can not be modified -> no problems) or if the object is already synchronized we wouldn't need to either (like if a StringBuffer object would be used here).

protected void method5(String param2) { // no shared resource and StringBuffer is thread safe
    new StringBuffer().append(param2).append(param2).append(param2);
}

That's already answered... we have no shared resource here, each thread creates it's own dedicated object and uses that

public synchronized String method6(int param2) {
    System.out.println("Thinking....");
    method7(5e-2);
    sb = new StringBuilder("Got it!"); // shared resource modified
    return sb.toString();
}

sb is answerded above. method7 call's return value isn't used so we don't need to look at this any further.

String method7(double param2) { // no shared resource
    return "" + param2;
}

method7 is using a paramater (similar to a local variable). We answered that above already. So we just have left method0

private void method0() {
    Double d = method3();
}

here method3 is called and as we have seen above we need to synchronize that method. Cause method3 is already synchronized we don't need to do that here again. That's all... good luck

Thanks, Thomas for your input. Interesting that a StringBuilder is not thread-safe and StringBuffer is thread-safe. Multi-threading has so much potential to screw up your application that choosing a thread-unsafe Class in a multi-thread app is a risk not worth taking. Here is an interesting video I found while researching threads 'Java's SimpleDateFormat is a Disaster Waiting to Happen' https://www.youtube.com/watch?v=JdNQoTJmzis