.NET identificateur d'objet unique

.NET 4 et plus tard seulement

Bonne nouvelle, tout le monde!

L'outil parfait pour ce travail est construit en .NET 4 et il est appelé ConditionalWeakTable<TKey, TValue>. Cette classe:

• peut être utilisé pour associer des données arbitraires avec la gestion des instances de l'objet comme un dictionnaire (bien qu'il est pas un dictionnaire)
• ne dépend pas des adresses de mémoire, donc, est à l'abri de la GC en compactant le tas
• ne pas garder les objets en vie juste parce qu'ils ont été inscrits en tant que clés de la table, de sorte qu'il peut être utilisé sans faire de chaque objet dans votre processus de vivre éternellement
• utilise la référence à l'égalité pour déterminer l'identité de l'objet; par ailleurs, la classe, les auteurs ne peuvent pas modifier ce comportement, donc il peut être utilisé constamment sur des objets de tout type
• peut être rempli à la volée, donc ne nécessite pas que vous injecter du code à l'intérieur de l'objet constructeurs

RuntimeHelpers.GetHashCode() peut aider (MSDN).

Comment de cette méthode:

Définir un champ dans le premier objet à une nouvelle valeur. Si le même champ dans la deuxième objet a la même valeur, c'est probablement la même instance. Sinon, la sortie comme différents.

Maintenant définir le champ dans le premier objet à une autre nouvelle valeur. Si le même champ dans la deuxième objet a changé à la valeur différente, c'est certainement la même instance.

N'oubliez pas de définir le champ dans le premier objet revenir à la valeur initiale à la sortie.

Problèmes?

Vous devez attribuer un tel identificateur de vous-même, manuellement, soit à l'intérieur de l'instance ou à l'extérieur.

Pour les dossiers liés à une base de données, la clé primaire peut être utile (mais vous pouvez toujours retrouver avec des doublons). Sinon, vous pouvez soit utiliser un Guid, ou de garder votre propre compteur, l'allocation de l'aide Interlocked.Increment (et de le rendre assez grande qu'il n'est pas susceptible de déborder).

Les informations que je donne ici n'est pas nouveau, je viens d'ajouter ce pour des raisons d'exhaustivité.

L'idée de ce code est assez simple:

• Objets ont besoin d'un IDENTIFIANT unique, ce qui n'est pas là par défaut. Au lieu de cela, nous devons compter sur la prochaine meilleure chose, qui est RuntimeHelpers.GetHashCode pour nous une sorte d'IDENTIFIANT unique
• Pour vérifier l'unicité, ce qui implique que nous devons utiliser object.ReferenceEquals
• Cependant, nous aimerions avoir un ID unique, j'ai donc ajouté un GUID, qui est par définition unique.
• Parce que je n'aime pas le verrouillage de tout, si je n'ai pas, je n'utilise pas ConditionalWeakTable.

Combiné, qui vous donnera le code suivant:

public class UniqueIdMapper
{
    private class ObjectEqualityComparer : IEqualityComparer<object>
    {
        public bool Equals(object x, object y)
        {
            return object.ReferenceEquals(x, y);
        }

        public int GetHashCode(object obj)
        {
            return RuntimeHelpers.GetHashCode(obj);
        }
    }

    private Dictionary<object, Guid> dict = new Dictionary<object, Guid>(new ObjectEqualityComparer());
    public Guid GetUniqueId(object o)
    {
        Guid id;
        if (!dict.TryGetValue(o, out id))
        {
            id = Guid.NewGuid();
            dict.Add(o, id);
        }
        return id;
    }
}

Pour l'utiliser, créez une instance de la UniqueIdMapper et utiliser le GUID est qu'elle renvoie pour les objets.

---

Additif

Donc, il y a un peu plus de choses ici; laissez-moi écrire un peu vers le bas sur ConditionalWeakTable.

ConditionalWeakTable fait un certain nombre de choses. La chose la plus importante est qu'il se complique pas de soins sur le garbage collector, c'est: les objets que vous avez de référence dans ce tableau seront recueillies indépendamment. Si vous recherche un objet, il fonctionne de la même manière que le dictionnaire ci-dessus.

Curieux non? Après tout, quand un objet est en train d'être recueillies par le GC, il vérifie si il y a des références à l'objet, et si il y a, il les collectionne. Donc si il y a un objet à partir de la ConditionalWeakTable, pourquoi l'objet référencé être collectées, puis?

ConditionalWeakTable utilise une petite astuce que certains autres .NET des structures aussi utiliser: au lieu de stocker une référence à l'objet, il stocke en fait un IntPtr. Parce que ce n'est pas une véritable référence, l'objet peut être recueilli.

Donc, à ce stade, il y a 2 problèmes à résoudre. Tout d'abord, les objets peuvent être déplacés sur le tas, alors, de quoi allons-nous utiliser comme IntPtr? Et deuxièmement, comment savons-nous que les objets ont un actif de référence?

• L'objet peut être épinglé sur le tas, et de son pointeur peut être stockée. Lorsque le GC atteint l'objet pour l'enlèvement, il unpins et de la recueillir. Cependant, cela signifierait que nous obtenons un épinglé des ressources, ce qui n'est pas une bonne idée si vous avez beaucoup d'objets (en raison de problèmes de fragmentation de mémoire). Ce n'est probablement pas la façon dont il fonctionne.
• Lorsque le GC déplace un objet, il appelle de nouveau, qui peut ensuite mettre à jour les références. Cela pourrait être la façon dont il est mis en œuvre à en juger par les appels externes dans DependentHandle - mais je crois que c'est un peu plus sophistiqué.
• Pas le pointeur vers l'objet lui-même, mais un pointeur dans la liste de tous les objets de la table est stockée. Le IntPtr est soit un indice ou d'un pointeur dans cette liste. La liste des modifications uniquement lorsqu'un objet changements de générations, à quel point un simple rappel peut mettre à jour les pointeurs. Si vous vous souvenez de la façon dont la Marque & Balayage fonctionne, cela fait plus de sens. Il n'y a pas d'épinglage, et le retrait est plus comme avant. Je crois que c'est la façon dont il fonctionne dans DependentHandle.

Cette dernière solution nécessite que l'exécution n'a pas ré-utiliser la liste des seaux jusqu'à ce qu'ils sont explicitement libéré, et il exige aussi que tous les objets sont récupérés par un appel à l'exécution.

Si nous supposons qu'ils utilisent cette solution, nous pouvons également aborder le deuxième problème. La Marque & algorithme de Balayage garde la trace de ces objets ont été recueillis; dès qu'il a été recueilli, nous savons à ce stade. Une fois l'objet de vérifier si l'objet est là, qu'il appelle "Libre", ce qui supprime le pointeur et l'entrée de la liste. L'objet est vraiment passé.

Une chose importante à noter à ce point, c'est que les choses tournent mal si ConditionalWeakTable est mis à jour dans plusieurs threads et si elle n'est pas thread-safe. Le résultat serait une fuite de mémoire. C'est pourquoi tous les appels en ConditionalWeakTable faire un simple "lock" qui assure que cela n'arrive pas.

Une autre chose à noter est que le nettoyage des entrées de a à se produire de temps en temps. Alors que les objets réels seront nettoyés par le GC, les entrées ne sont pas. C'est pourquoi ConditionalWeakTable ne pousse que dans la taille. Une fois qu'il atteint une certaine limite (déterminé par la collision de chance dans la table de hachage), il déclenche une Resize, qui vérifie si les objets doivent être nettoyés -- s'ils le font, free est appelé dans la GC processus de retrait de la IntPtr poignée.

Je crois que c'est aussi pourquoi DependentHandle n'est pas exposé directement - vous ne voulez pas salir avec les choses et une fuite de mémoire comme un résultat. La prochaine meilleure chose est que une WeakReference (qui stocke également une IntPtr au lieu d'un objet), mais, malheureusement, ne comprennent pas la "dépendance" aspect.

Ce qui reste est pour vous de jouet autour de la mécanique, de sorte que vous pouvez voir la dépendance dans l'action. Assurez-vous de commencer plusieurs fois et de regarder les résultats:

class DependentObject
{
    public class MyKey : IDisposable
    {
        public MyKey(bool iskey)
        {
            this.iskey = iskey;
        }

        private bool disposed = false;
        private bool iskey;

        public void Dispose()
        {
            if (!disposed)
            {
                disposed = true;
                Console.WriteLine("Cleanup {0}", iskey);
            }
        }

        ~MyKey()
        {
            Dispose();
        }
    }

    static void Main(string[] args)
    {
        var dep = new MyKey(true); //also try passing this to cwt.Add

        ConditionalWeakTable<MyKey, MyKey> cwt = new ConditionalWeakTable<MyKey, MyKey>();
        cwt.Add(new MyKey(true), dep); //try doing this 5 times f.ex.

        GC.Collect(GC.MaxGeneration);
        GC.WaitForFullGCComplete();

        Console.WriteLine("Wait");
        Console.ReadLine(); //Put a breakpoint here and inspect cwt to see that the IntPtr is still there
    }