First, the fact is that it's threads that are actually running and seeking & releasing locks. Every instance in the RAM is represented by at least a
thread.
Then, let's take a close look at the lock issue:
When the instance (or a thread) is running and is up to the time to invoke a synchronized lock, it enters the stage of lock-seeking. If seeking fails, it may try again later. If seeking succeeds, the instance (or the thread) gets the lock and run the code inside the synchronized method and release the lock upon finishing. The instance (or the thread) can't do anything else simultaneously, except for that it starts another thread. The started thread may encounter synchronized method and goes through the same necessary stages.
Therefore, the question of "Whether an instance or the invoking method owns the synchronized method?" is answered by the fact that an instance (or a thread) can't do anything else when running in a invoking method of a synchronized method. Then, either of the two can be said to own the lock.
However, the question of "whether an instance can have multiple locks?" boils down to a question of "whether an instance can be run in multiple threads?". In most cases, that's not the case.