Quite hard take an article seriously with this line in it:
int hour = order.timestamp().atZone(ZoneId.systemDefault()).getHour();
(Because... does the hour you did the thing change according to where you run the code? no - it should use either the location of the trader, or the exchange, neither of which are related to where the code runs)
Using strings as different kinds ids is kind of an anti pattern too. They are IDs in different domains. They can be a strongly-typed long (or other type, uuid, snowflake, whatever). No string concatenation required. This then carries on to the regular expressions - if you use strong types, you then don't need to validate that the stringly-typed stuff you used earlier, and hopefully didn't permute some function arguments somewhere is actually valid.. it just is)
The example shows rentrantlock for a single entire method.. there's no huge advantage over synchronised in this case.. maybe there's other code thats not shown.
Using double for prices & costs? You really need to be much more sure about what number of money you really have. I cant pay you $2.19999999999999.
If you have a cpu-bound algorithm, running vastly more threads than cpus isn't ever going to help, and if you really have 200 cores, then you'll want to modify your algorithm to remove synchronization... thanks Amdahl!
There may be some suggestions in the article, but it feels forced.
edit: added details on timezones, validation & threads.
Quite hard take an article seriously with this line in it:
int hour = order.timestamp().atZone(ZoneId.systemDefault()).getHour();
(Because... does the hour you did the thing change according to where you run the code? no - it should use either the location of the trader, or the exchange, neither of which are related to where the code runs)
Using strings as different kinds ids is kind of an anti pattern too. They are IDs in different domains. They can be a strongly-typed long (or other type, uuid, snowflake, whatever). No string concatenation required. This then carries on to the regular expressions - if you use strong types, you then don't need to validate that the stringly-typed stuff you used earlier, and hopefully didn't permute some function arguments somewhere is actually valid.. it just is)
The example shows rentrantlock for a single entire method.. there's no huge advantage over synchronised in this case.. maybe there's other code thats not shown.
Using double for prices & costs? You really need to be much more sure about what number of money you really have. I cant pay you $2.19999999999999.
If you have a cpu-bound algorithm, running vastly more threads than cpus isn't ever going to help, and if you really have 200 cores, then you'll want to modify your algorithm to remove synchronization... thanks Amdahl!
There may be some suggestions in the article, but it feels forced.
edit: added details on timezones, validation & threads.
Part 2 of 3 in the Java Performance Optimization series.