The risk you run right now is the "race condition". Thread1 might increment pcUniqueName and then Thread2 might increment it again before T1 returns. So T1 and T2 might return the same value. The fix is to synchronize the method or the smallest possible block of code around the incrementer. That will force the 50 portlets to come through the method single-file. Since the method is very fast synchronizing the method won't hurt much.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
What Stan said goes, but I wanted to give you a little background.
First, "Deadlock" always refers to an interaction that happens when two threads try to lock two different objects in the opposite order. In a deadlock situation, thread A has locked object 1 and is waiting to lock object 2; which thread B has locked object 2 and is waiting to lock object 1. The two threads will wait forever, and this is called a "deadlock." This has nothing to do with your current situation, as there's only one object being used, and in fact no locking at all.
Second, note that threads don't block eachother from calling unsynchronized methods. As Stan describes, many threads can be inside the same unsynchronized method on the same object at the same time. If they're all modifying a common resource, as here, then this is a recipe for disaster!
I'm going to move this to our "Threads and Synchronization" forum.