I have to generate a unique Id which is readable as well hence cannot use UUID. So I thought of using Instant.toEpochMilli(). Can it be used as unique id?
-
As long as you are sure there are no two or more objects created within one millisecond, then maybe... For what kind of object do you have to create an id? – deHaar Sep 26 '18 at 09:40
-
What type of objects are you trying to generate ids for? – Alex M Sep 26 '18 at 09:42
-
3How is `Instant.toEpochMilli` more readable than an UUID? – marstran Sep 26 '18 at 09:44
-
2How is epoch milli more readable than UUID? The latter prints much nicer if you need to read it off in its default format with groups and dashes. – Thilo Sep 26 '18 at 09:44
-
1That will never be guaranteed to be unique unless you wrapper it to enforce that convention and may still cause issues in multithreaded usage, unless done correctly. Instead use a random UUID and convert to a String. UUID.randomUUID().toString() – Martin Spamer Sep 26 '18 at 09:54
-
1don't do it - you cannot be absolutely certain that you will not get the same ID - this depends on the machine, on the system, on the implementation of the virtual machine, on temperature, ... Example: you do not know the resolution of the clock used to get the time. See doc of `System.currentTimeMillis`, which **may** be used by `Instant`: " Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds." – user85421 Sep 26 '18 at 10:01
-
**Type of objects** : So I have an Orders object with a order object inside it. Every order object should have a unique order-id. - **Readable** : By looking at it I can tell the sequence of the orders created and elasticsearch has date datatype so it might help with reporting later - **Guarantee** : As @MartinSpamer mentioned I have a wrapper around the method and the call is synchronized. As I dont see a lot orders beign uploaded I did not think of it as being a bottle neck. – humbleCoder Sep 27 '18 at 09:26
3 Answers
No. I personally faced with situation, when two objects had same id. I have tested System.nanoTime()
and it looked OK, but in general case both variants are not correct.
Correct solutions:
UUID.randomUUID()
AtomicLong
- Database sequence

- 17,377
- 4
- 21
- 35
-
1not even nanoTime is good, it has nano precisions, but not nano accuracy – Eugene Sep 26 '18 at 21:28
-
Can it be used as unique id?
Only if you can be certain that you won't allocate two IDs within the same millisecond, which seems unlikely. A millisecond is a really brief time to a human being, but it isn't a brief time to a computer, not at all.
If you're doing this within a given runtime environment and don't have to have unique IDs between environments, just use an ever-increasing number instead (if it only needs to be within the running process, this can just be a static field somewhere you increment as necessary; across processes but in the same overall environment, a database sequence or similar; etc.). If it has to be unique between environments, you really do need to use a GUID or similar.

- 1,031,962
- 187
- 1,923
- 1,875
It generates the current time in millisecond. Well, in most cases, it is not good enough. Because if the timeout between 2 calls of this method is too short(ex: when you call it in the loop) it might be dupplicated. You may want to take a look at generating nanosecond(for example System.nanoTime()). To sum up, it's not encouraged to use millisec or even nano sec as unique id. But in some particular loose situations, it can be accepted.

- 9
- 2
-
2not sure if `nanoTime` is much better - javadoc: "This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of currentTimeMillis()." – user85421 Sep 26 '18 at 10:05
-
1Agree, in my opinion, nanoTime is slightly better than timeMillis but both of them are not enough to play as unique ID – Tonyyy Sep 26 '18 at 10:20