J'ai examiné le code, tout est INT - le paramètre transmis au CountownLatch Construct est INT, la variable de synchronisation est INT, le type de retour de synchronisation SYNC.GETCOUNT () est INT. Mais CountTownLatch.GetCount () retourne longtemps? Se demandant pourquoi.
4 Réponses :
Je ne sais pas si vous trouverez une réponse suffisante à cette question à moins que quelqu'un qui a conçu que API répond, mais il dit que c'est pour "débogage et test".
public long getCount() {...} // just for debugging and testing
Oui ... dans Multhread env, cette valeur n'est pas fiable. Je demande à cette quête, je me demandais pourquoi utiliser long ... merci!
AVERTISSEMBLEMENTAIRE?
Juste parce que CountownLatch (int) est le seul constructeur existant, qui ne signifie pas que vous ne pouviez pas ajouter CountownLatch (Long) en Java 8, si quelqu'un vient jamais avec une utilisation pour ce genre de chose.
La valeur est uniquement indicative, non fiable, de toute façon.
Je suppose que c'est parce que l'INT est utilisé pour stocker un INT non signé, comptant de 0 à 2 ** 32-1. Bien que vous puissiez stocker un INT non signé dans un int, lorsque vous effectuez des calculs avec elle, il est beaucoup plus facile de promouvoir la valeur à une longue, ce qui peut accueillir cette gamme tout naturellement.
Merci, cela explique beaucoup.
J'ai une idée différente: surveillance simple.
Lorsque vous vous tournez vers le code source, vous constaterez que l'implémentation utilise une synchronisation de classe interne. Sync a un getcount (), aussi - et celui-ci retourne int. En d'autres termes: l'ensemble de la mise en œuvre est basé sur INT; et seulement celui-là externe utilise longtemps. Je pense qu'il n'y a pas de sens à cela.