Est-ce que match (Uri) de la classe UriMatcher est réentrant?

Question

Les exemples que je l'ai vu de la façon de faire un ContentProvider ont tous utilisé la méthode UriMatcher#match(Uri) dans les insert, query, update et delete méthodes pour gérer facilement tous les modèles d'URI que le fournisseur de contenu répond à (par exemple: http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NotePadProvider.html) . Cela me semblait correct jusqu'à aujourd'hui, quand j'ai remarqué sur la documentation ContentProvider API que insert, query, update, et delete "peut [tous] être appelé à partir de plusieurs threads". En outre, la documentation UriMatcher ne dit rien sur la sécurité des threads ou si match est réentrante.

Ai-je besoin de vous soucier de la synchronisation des appels à match sur une commune, static instance de UriMatcher qui est utilisé dans mes implémentations de insert, query, update et delete?

Answer 1

En regardant à travers the source of UriMatcher, il apparaît que plusieurs threads peuvent appeler la méthode match simultanément, car la mise en œuvre de match accède uniquement au par thread variables uri (paramètre), partagé String s, et éléments d'un ArrayList<UriMatcher> (via ArrayList#get(int), qui est thread-safe).

addURI est pas thread-sûr car il modifie structurellement un ArrayList. Il s'agit de la même ArrayList que lit match, donc addURI ne peut pas être appelée pendant que d'autres unités d'exécution appellent éventuellement match.