Not if they are RFC 4122 UUIDs (more accurately, they are insufficiently cryptographically secure): even the random ones are only 122 bits, which only provide 61 bits of security.
UUIDs are still really, really useful. I don't recommend not using them unless one understands why and when not to.
Why would that be? You can fork your PRNG as many times as you have threads in initialization, so there's no need for IO. And secure ones do spend many times more CPU than the cheapest PRNG available, both would be a rounding error on the performance on nearly all real world work-loads.
I'd support removing non-secure random functions from every standard library out there.
~ $ python -m timeit -s 'import uuid' 'uuid.uuid4()'
100000 loops, best of 3: 14.2 usec per loop
Which gives more than 70000 random UUIDs per second.Ah, Java...
The library you are using for creating those UUIDs must have some bug. My guess is they share the same generator for all threads on each machine.
It is a cryptographically secure PRNG, but during a small time in system start up, it may not be correctly seeded.
If you need long term keys, it may be better to get some 256 bits from /dev/random before using /dev/urandom.
http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
I support UUIDs instead of nearly any other id space. They solve collision problems completely. Its time to stop managing ids.