can we put thread join method inside synchronized method

Question

Can I use thread.join inside a synchronized method?

class Table{  
 synchronized void printTable(int n){//synchronized method  
   for(int i=1;i<=5;i++){  
     System.out.println(n*i);  
     try{  
      Thread.join(); 
     }catch(Exception e){System.out.println(e);}  
   }  
 }  
}  

can I use thread.join instead of wait?

Answer 1

First of all:
No compilation or runtime exceptions but please consider below two points may be you don't want want to do it after that. :)
Joining a thread means that one waits for the other to end, so that you can safely access its result or continue after both have finished their jobs.All overloaded versions of join() are final and synchronized.
Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object's variables are done through synchronized methods.

Answer 2

It's very unclear what you're trying to do here. It appears you might be misunderstanding what the synchronized keyword does and where the locks are that are used in your example.

The line Thread.join(); is not valid since it's an instance method. It's not apparent what thread you actually want to join. You would need to provide a reference to whatever thread it is whose termination you want to wait for.

Here's the Java tutorial description of Thread#join :

The join method allows one thread to wait for the completion of another. If t is a Thread object whose thread is currently executing,

t.join();

causes the current thread to pause execution until t's thread terminates. Overloads of join allow the programmer to specify a waiting period. However, as with sleep, join is dependent on the OS for timing, so you should not assume that join will wait exactly as long as you specify.

It's not apparent why you would perform this join in a for-loop, because the join method waits until the thread is completely finished (as in no longer alive), multiple calls to it wouldn't seem useful. (Are there multiple threads you need the current thread to join to? Or you're expecting to provide a timeout value and repeatedly try to join the same thread?)

In your comment, when you ask:

simple question about can I use thread.join instead of wait

you can't use one as a drop-in replacement for the other. The lock held by the synchronized method is not the same as the lock used (acquired, released, then re-acquired) by the join. The join method uses the lock on the thread, wait has to use the lock on the Table instance (the lock used by the synchronized method). Calling wait from within the synchronized method will release the lock on the Table instance (giving other threads a chance to access that instance), but calling join will not. Since the synchronized method is holding a lock on the instance of Table, that means your thread is denying any other thread access to that Table instance until whatever thread it's joining finishes. Although join is implemented using wait, what it's waiting for is a notification from the monitor on the thread you're joining, not on the Table object, so the lock on the Table instance never gets released until the method completes, which depends on the joins completing. The thread is going dormant while holding a lock; if other threads need to access this Table object then you are denying those other threads access with this approach.

So (assuming you add some logic to provide the reference to whatever thread or threads that your current thread needs to join to) you can do this, but it seems horrible. Threads should minimize the time they spend holding locks. Possibly a higher-level construct like CyclicBarrier could be useful here (though you still shouldn't hold onto a lock while doing this either).