Je suppose que les appels provenant de threads distincts (> 15) ont un effet négatif sur les performances. Y a-t-il une meilleure façon d'obtenir l'heure du système dans les applications concurrentes?Goulot d'étranglement des performances dans les appels simultanés à System.currentTimeInMillis()
Juste un petit conseil:
J'ai lu des ingénieurs de Google et d'autres programmeurs qu'il est préférable d'utiliser System.nanoTime. Par exemple joshua bloch
Pour la synchronisation d'intervalle, utilisez toujours System.nanoTime de préférence à System.currentTimeMillis
Ne répond pas à la question. En outre, même en fonction de votre devis, System.nanoTime est préféré pour la synchronisation d'intervalle, il n'y a aucune mention de ce que l'OP utilise l'heure du système pour. La synchronisation d'intervalle peut ne pas être applicable ici. –
Peut-être que cela ne répond pas directement à la question, mais je pense que d'autres personnes ont déjà répondu à la question, alors je ne faisais que donner un pourboire. – Alfred
http://www.techper.net/2008/08/10/systemcurrenttimemillis-systemnanotime-and-their-resolution/ timeinMillis a des problèmes avec la granularité de MS Windows –
Si c'est vraiment un problème, vous pouvez avoir un thread de fond stocker l'heure actuelle dans un volatile. Ou appelez-le moins souvent.
+1 - il y a certainement quelque chose d'un peu bizarre dans une application qui doit faire des appels fréquents à 'System.currentTimeMillis'. –
Je ne le crois pas, la plupart des systèmes d'exploitation fournir un bon support pour ce type de fonction et il est probablement implémenté comme une méthode native. Pourquoi blâtes-tu cette méthode pour tes problèmes de performances? –
Quel profilage avez-vous fait qui montre que cette fonction est le problème? –