Когда CLR говорит, что объект имеет финализатор?
Да, вы отправляете отчет на хост 10.0.0.203:10000, поэтому вам нужен порт прослушивания программы 10000 на 10.0.0.203. В противном случае Flink не сможет отправить ему сообщение. В этом случае вам нужно запустить Graphite на этом хосте. См. документ .
4 ответа
Вопросы 1 и 2: CLR в основном проверяет, переопределяется ли финализатор. Если это не, это рассматривает его как не наличие финализатора.
Преимущество наличия финализатора в Системе. Объект состоит в том, что компиляторы знают, что они могут всегда помещать вызов в base.Finalize() в. Это избегает проблем управления версиями. Рассмотрите мир без System.Object.Finalize():
- Система. Объект (не завершают),
- Высшая точка. BaseClass (не завершают),
- MyCompany. DerivedClass (Завершают)
Без a Finalize метод в объекте, финализатор в MyCompany. DerivedClass ничего не может назвать. Который приводит к проблеме когда версия 2 Высшей точки. BaseClass выпускает финализатор. Если Вы не перекомпилировали MyCompany. DerivedClass, экземпляр DerivedClass будет завершен, не называя BaseClass. Завершите, который является ясно Плохой Вещью.
Теперь рассмотрите ту же ситуацию с Системой. Объект. Завершите - компилятор вставляет вызов для базирования. Завершите автоматически в DerivedClass. Завершите, который в версии 1 просто не называет никакую-op реализацию в Системе. Объект. Когда версия 2 Высшей точки. BaseClass выходит, вызов к base.Finalize будет (без перекомпиляции DerivedClass), называют BaseClass. Завершить.
Вопрос 3: Нет, у Вас не должно быть финализатора просто, потому что Вы реализуете IDisposable. Финализаторы должны только использоваться для неуправляемых ресурсов, которые ничто иное не собирается очистить - т.е., к которым у Вас есть прямая ссылка. Например, предположите, что у Вас есть класс, который имеет a FileStream членская переменная. Вы хотите реализовать IDisposable таким образом, можно закрыть поток как можно скорее, если вызывающая сторона помнит - но если они не помнят звонить Dispose(), поток станет имеющим право на сборку "мусора" в то же время, что и Ваш объект. Доверяйте этому FileStream имеет соответствующий финализатор (или ссылка на что-то еще с финализатором и т.д.) вместо того, чтобы пытаться очистить его в Вашем собственном финализаторе.
С.NET 2.0, с классом SafeHandle, должно быть невероятно редко для Вас нуждаться в Вашем собственном финализаторе.
1: Это только действительно рассчитывает (в полезном смысле), если это было переопределено
2: Как определено 1, и GC.SuppressFinalize не был назван (плюс, потворяют регистрацию и т.д.),
3: конечно, нет; на самом деле, если Вы непосредственно не обрабатываете неуправляемый ресурс, у Вас не должно быть финализатора. Вы не должны добавлять финализатор просто, потому что это - IDisposable - но вещи, которые имеют финализаторы, должен также обычно быть IDisposable.
- Нет, это не означает так. Только переопределенный
Finalize()рассчитает CLR. - При наличии финализатора, как определено выше.
- Нет, это не всегда необходимо. Это - просто хороший шаблон. Я имею в виду, никто не вынуждает Вас сделать так. Но это - хорошая вещь сделать, если у Вас будут неуправляемые ресурсы, с тех пор если кто-то забудет располагать его, то неуправляемый ресурс будет выпущен когда-то. FxCop не осуществляет строгие правила. Это осуществляет хорошие шаблоны, которые могут привести к отказу в будущем, если Вы не заботитесь о.
ОБНОВЛЕНИЕ: Каждый класс ответственен за управление его собственными ресурсами. Из-за функций абстракции и инкапсуляции объектно-ориентированных парадигм, потребитель класса не должен заботиться, о каких ресурсах он имеет, косвенно. Поэтому необходимо или вручную высвободить средства, Вы владеете (чем Вы владеете, то, что Вы непосредственно собственный, поскольку Вы смотрите на другие вещи как на черный квадрат) или предоставляют GC право выпускать их. Для неуправляемых ресурсов у Вас нет опции оставить это GC, таким образом, необходимо выпустить его вручную. В этом смысле SafeHandle, который упомянул Jon, является управляемой абстракцией неуправляемого ресурса, поэтому его нужно рассматривать как ценный управляемый ресурс (который является черным квадратом, который справляется с завершением того неуправляемого ресурса самого).
1) Да (на основании наследования)
2) Ничто не содержит ссылку на экземпляр класса (который сделает его имеющим право на завершение),
3) Да (почему нужно реализовать IDisposable, если он не требует, пользователь для явного вызова располагает? Классы соединения в .NET используют umanaged ресурс под капотом и если Вы не звоните, располагают на нем, он будет держаться за него. Так как синхронизация GC неизвестна, соединение останется открытым до того времени),
Это - мое понимание.
Я мог быть неправым. В этом случае эксперты исправят вещи для меня.