如何在Delphi中开始构建可搜索的垃圾收集器（2009-2010） [英] How to start building a searchable garbage collector in Delphi (2009-2010)

问题描述

我正在寻找一种方法来控制我在Delphi中编写的应用程序中创建的所有业务对象。

I'm looking for a way to control all business objects I create in my applications written in Delphi.

作为Embarcadero的EDN文章（ http://edn.embarcadero.com/article/28217 ）说，基本上有三种方法。我最感兴趣的是最后一个，使用界面。这样，当业务对象在应用程序中的任何地方都不再被引用时，它会被内存处理（稍后我会再回来）。

As an article on Embarcadero's EDN (http://edn.embarcadero.com/article/28217) states, there are basically three ways to do this. I'm mostly interested in the last one, using interfaces. That way, when the business object is no longer being referenced anywhere in the application, it will be dispose of memory wise (I'll get back on this part later).

创建新的业务对象时，请问新对象管理器是否已经在程序中提前获取了该对象管理器，因此避免了将其从数据库。我已经有内存中的业务对象，所以为什么不使用那个？因此，我需要内存中可用对象的列表可以被搜索（快速）。

When creating a new business object, it would be wise to ask that new object manager whether I already fetched it earlier in the program, thus avoid the need to refetch it from the database. I already have the business object in memory, so why not use that one? Thus I'll need the list of available objects in memory to be searchable (fast).

所提供的代码使用数组TObject来存储收集的对象，这不会使您在获取对象的列表中非常有效到一定量我必须将它改为TObjectList或某种二进制搜索树。这将是最好的选择？我已经在 http://www.ibrtses.com/delphi找到一些有用的代码（我想） /binarytree.html 。没有JCL在二叉树上有东西？

The provided code there uses an "array of TObject" to store the collected objects, which doesn't make it very performant concerning searches through the list of objects once you get to a certain amount. I would have to change that to either TObjectList or some sort of binary searchable tree. What would be the best choice here? I already found some useful code (I think) at http://www.ibrtses.com/delphi/binarytree.html. Didn't JCL have stuff on binary trees?

我该如何处理该树中的业务对象和业务对象列表？作为列表的一部分的业务对象在树中被引用两次？

How would I handle "business objects" and "lists of business objects" in that tree? Would a business object, being part of a list be referenced twice in the tree?

关于处理对象：我还想设置某种TTL（时间生活）到该业务对象，在一定时间后强制重新提取。
如果引用计数器为0，我仍然希望将对象保留一定的时间，程序仍然需要TTL。这意味着我需要排序的线程监视器循环对象列表（或树）来观看被删除的对象。

Concerning the disposing of an object: I also want to set some sort of TTL (time to life) to that business object, forcing a refetch after an certain amount of time. Should the reference counter fall to 0, I still want to keep the object there for a certain amount of time, should the program still want it within the TTL. That means I'll need sort sort of threaded monitor looping the object list (or tree) to watch for to-be-deleted objects.

我也遇到了Boehm垃圾收集器DLL（ http://codecentral.embarcadero.com/Download.aspx?id= 21646 ）。

I also came across the Boehm Garbage Collector DLL (http://codecentral.embarcadero.com/Download.aspx?id=21646).

所以简而言之，将我的对象管理器放在EDN文章中提供的源代码上是明智的我想要存储我的对象的清单是什么？我应该如何处理列表中的对象列表？我还应该保持我的对象一段时间，并通过线程监视器处理？

So in short, would it be wise to base my "object manager" on the source code provided in the EDN article? What kind of list would I want to store my objects in? How should I handle list of objects in my list? And should I still keep my object in memory for a while and have it dispose of by a threaded monitor?

我的理由是正确的吗？任何建议，想法或备注之前，我开始编码？也许一些新的想法可以纳入我的代码？

Am I correct in my reasoning? Any suggestions, ideas or remarks before I start coding? Maybe some new ideas to incorporate into my code?

Btw，我会很乐意分享结果，让别人受益，一旦有一些辉煌的思想给了它一个想法

Btw, I'd be happy to share the result, for others to benefit, once some brilliant minds gave it a thought.

Thnx。

推荐答案

如果您使用Interfaces进行参考计数，然后将它们粘贴在某种类型的集合中，那么您将始终有对它们的引用。如果您的目标是垃圾收集，那么您只需要一个或另一个，但是如果需要，您一定可以使用。

If you are using Interfaces for reference counting, and then stick those in a collection of some sort, then you will always have a reference to them. If your objective is "garbage collection" then you only need one or the other, but you can certainly use both if necessary.

您真正想要的是一个业务对象缓存。为此，您将需要使用新的通用 TDictionary 集合之一。你可能想要做的是一个TDictionary的TDictionary集合，一个TDictionary为每个对象类型。你可以在一个枚举上键入你的主要TDictionary，或者甚至可以在对象本身的类型上（我没有尝试过，但是它可能会起作用）。如果你使用GUID作为唯一的标识符，那么你可以把它们全部放在单一的TDictionary。

What it sounds like you really want is a business object cache. For that you will want to use one of the new generic TDictionary collections. What you might want to do is have a TDictionary of TDictionary collections, one TDictionary for each of your object types. You could key your main TDictionary on an enumeration, or maybe even on the type of the object itself (I haven't tried that, but it might work.) If you are using GUIDs for your unique identifiers then you can put them all in a single TDictionary.

使用界面实现每个业务对象。您不需要使用智能指针，因为您正在设计业务对象并可以从TInterfacedObject下降它们。然后只能通过它的接口引用它，所以它可以被引用计数。

Implement each of your business objects with an interface. You don't need to use Smart Pointers since you are designing your business objects and can descend them from TInterfacedObject. Then only reference it by its interface, so it can be reference counted.

如果你想要使缓存过期，那么你需要在你的对象上有一些时间戳每当从缓存中检索到一个对象时，它将被更新。然后，当缓存超过一些特定的大小时，您可以修剪所有旧的旧的时间戳。当然这需要走整个缓存来做到这一点。

If you want to expire your cache then you will need to have some sort of timestamp on your objects that gets updated each time an object is retrieved from the cache. Then when the cache gets over some specific size you can prune everything older then a certain timestamp. Of course that requires walking the entire cache to do that.

由于您正在组合界面和集合，因此如果您有一个对象（通过其接口）的引用，并且在缓存清理期间被修剪，则对象将保持活着，直到参考消失。这为您提供了额外的安全性。当然，如果你仍在使用引用，那么这意味着你保留了很长一段时间的引用，而不是从缓存中检索出来。在这种情况下，您可能希望在读取或写入属性时更新时间戳。 。 。很多这取决于您将如何使用业务对象。

Since you are combining interfaces and a collection then if you have a reference to an object (via its interface), and it gets pruned during cache cleanup, then the object will remain alive until the reference goes away. This provides you an additional safety. Of course if you are still using the reference, then that means you kept the reference for a long time without retrieving it from the cache. In that case you may want to update the timestamp when you read or write to the properties too . . . A lot of that depends on how you will be using the business objects.

只要重新获取，只需要从缓存中检索对象即可大于提取限制。这样，如果在再次使用它之前修剪了它，那么您不会浪费数据库访问。

As far as refetching, you only want to do that if an object is retrieved from the cache that is older then the refetch limit. That way if it gets pruned before you use it again you are not wasting database trips.

您可能会考虑在每个表中最后修改时间。然后，当您从缓存中获取对象时，只需在数据库中检查内存中的时间。如果对象自上次检索以来已被更改，您可以对其进行更新。

You might consider just having a last modified time in each table. Then when you get an object from the cache you just check the time in memory against the time in the database. If the object has been changed since it was last retrieved, you can update it.

只有当对象从高速缓存中检索时，才会限制更新对象。这样，在使用对象时，您就不太可能修改该对象。如果您正在从对象读取数据，同时更改可能会产生一些非常奇怪的行为。有几种方法来处理，具体取决于您使用的方式。

I would limit updating objects only to when they are being retrieved from the cache. That way you are less likely to modify the object while it is use. If you are in the middle of reading data from an object while it changes that can produce some really odd behavior. There are a few ways to handle that, depending on how you use things.

关于使用界面的警告词，您不应该将对象和接口引用到同一个目的。这样做可能会导致引用计数的麻烦，并导致对象被释放，同时还有一个对象引用。

Word of warning about using interfaces, you should not have both object and interfaces references to the same object. Doing so can cause trouble with the reference counting and result in objects being freed while you still have an object reference.

我相信会有一些反馈，所以选择什么听起来像是最好的解决方案。 。 。

I am sure there will be some feedback on this, so pick what sounds like the best solution for you. . . .

当然，现在我已经写了所有这些，我会建议你看看某种业务对象框架。 RemObjects 有一个很好的框架，我相信还有其他的。

Of course now that I have written all of this I will suggest you look at some sort of business object framework out there. RemObjects has a nice framework, and I am sure there are others.

这篇关于如何在Delphi中开始构建可搜索的垃圾收集器（2009-2010）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！