Java乐观锁的局限性主要包括以下几点：
- 并发冲突概率较高：乐观锁假设并发冲突的概率较低，因此在数据被修改之前不会进行任何加锁操作。然而，在高并发场景下，多个线程可能同时读取到相同的共享数据，并尝试对其进行修改，从而导致并发冲突。这种情况下，乐观锁需要重新读取数据并尝试修改，增加了系统开销和响应时间。
- 无法解决大量并发读写问题：乐观锁适用于读多写少的场景，因为写操作会导致数据被锁定，影响其他线程的读操作。在大量并发读写的场景下，乐观锁的性能可能会受到严重影响。相比之下，悲观锁通过在数据被修改之前加锁，避免了并发冲突，但可能会阻塞其他线程的读写操作。
- 需要处理“脏读”问题：使用乐观锁时，可能会出现“脏读”的情况，即一个线程读取到的数据是另一个线程尚未提交的数据。这种情况下，读取到的数据可能是不一致或不完整的，需要额外的机制来处理这种情况。
- 无法回滚事务：乐观锁通常与数据库事务一起使用，但在某些情况下，可能需要回滚事务。然而，由于乐观锁不会在数据被修改之前加锁，因此可能无法正确地回滚事务，导致数据不一致。
需要注意的是，以上局限性并不意味着乐观锁在所有场景下都是不可用的。在实际应用中，需要根据具体的业务需求和并发情况选择合适的锁机制。在某些场景下，可以通过结合使用乐观锁和悲观锁或其他并发控制技术来克服这些局限性。