Будет.Net Garbage Collect объект, на это не ссылаются, но имеет поток, это делает работу?
cw
Изменить слово - удаляет слово под курсором и переводит вас в режим вставки для ввода нового слова. Конечно, это работает с другими клавишами перемещения, поэтому вы можете сделать что-то вроде c $ , чтобы перейти к концу строки.
f + символ
Находит следующее вхождение символа в текущей строке. Таким образом, вы можете сделать vft , чтобы выделить весь текст до следующей буквы «t» в текущей строке. Это еще одна клавиша перемещения, поэтому она работает и с другими командами.
5 ответов
Нет, поток считается работающим до тех пор, пока на него есть ссылка, и любой запущенный поток считается упомянутым (IIRC, выполняющийся поток регистрирует свой стек как корень GC, и это стек будет ссылаться на поток).
Тем не менее, я смотрю на ваш пример и не понимаю, где, по вашему мнению, создается поток?
Нет, стек работающего потока действует как корень для целей GC. Этот стек будет жить до тех пор, пока поток работает, поэтому сам поток не будет собираться, пока он работает.
Вот статья , в которой упоминается (среди прочего), для чего нужны корни. Цели GC. Для экономии времени корни GC - это глобальные объекты, статические объекты, все ссылки на все стеки потоков и все регистры ЦП, содержащие ссылки.
На ваш вопрос немного сложно ответить. Как и Джоэл, насколько я могу судить, у вас нет ничего в стеке, ссылающегося на ваш таймер, который сам по себе является единственным, что ссылается на поток. Учитывая это, можно было ожидать, что экземпляр Thinker будет собран.
Мне было любопытно по этому поводу, и мне нужно было более конкретное объяснение того, что может произойти, поэтому я немного покопался в Reflector. Как оказалось, System.Timers.Timer в конечном итоге создает System.Threading.Timer, который внутренне создает экземпляр TimerBase, внутреннего класса. TimerBase является производным от CriticalFinalizerObject, который является системным типом, который гарантирует, что весь код в области ограниченного выполнения (CER) будет выполняться до того, как реализующий класс будет полностью завершен и отброшен GC. TimerBase также является IDisposable, и его метод dispose зацикливается и ожидает до тех пор, пока блокировка не будет снята. На этом этапе я начал работать с внешним кодом, поэтому я не совсем уверен, как блокировка инициализируется или снимается.
Однако, основываясь на том, как написан класс TimerBase, на том факте, что он является производным от CriticalFinalizerObject, и на том факте, что его удаление ожидает спин-ожидания до тех пор, пока блокировка не будет снята, я думаю, можно с уверенностью сказать, что поток, на который ничего не ссылается не будет завершен, пока этот код не будет выполнен. Тем не менее ... важно отметить, что он, скорее всего, будет обработан сборщиком мусора ... вполне возможно, более одного раза, поскольку финализация может значительно удлинить процесс сбора финализированных объектов. Для объектов CriticalFinalizerObjects процесс финализации может занять еще больше времени, если активно выполняется код, который, как гарантирует CER, будет полностью выполняться.
Это может означать, что у вас есть прямо противоположная проблема, если вашим Мыслителям требуется время для выполнения. Вместо того, чтобы эти объекты собирались преждевременно, они пойдут на длительную доработку, и все, на что они ссылаются, попадет в gen2 и проживет некоторое время, пока GC, наконец, не сможет полностью их собрать.
Это может означать, что у вас есть прямо противоположная проблема, если вашим Мыслителям требуется время для выполнения. Вместо того, чтобы эти объекты собирались преждевременно, они пойдут на длительную доработку, и все, на что они ссылаются, попадет в gen2 и проживет некоторое время, пока GC, наконец, не сможет полностью их собрать.
Это может означать, что у вас есть прямо противоположная проблема, если вашим Мыслителям требуется время для выполнения. Вместо того, чтобы эти объекты собирались преждевременно, они пойдут на длительную доработку, и все, на что они ссылаются, попадет в gen2 и проживет некоторое время, пока GC, наконец, не сможет полностью их собрать.
Если я правильно это читаю (а я мог бы быть далеко), его можно собрать, потому что он не в настоящее время ничего делает.
Если бы у вас были локальные переменные в вашем стартовом методе, и этот метод все еще был активен, эти переменные все еще были бы «в области видимости» в стеке и обеспечивали корень для вашего потока. Но единственная переменная, которую вы используете, - это ваш частный таймер, и поскольку он связан с самим потоком, а у потока нет ничего в стеке, ничего не остается, чтобы поддерживать его в рабочем состоянии.
I agree and disagree, If the reference to the thread object is lost the thread will be terminated and garbage collected. In your case it might not be as such because it is not directly using threads and is using timer. But if you had called a method in a thread and the thread reference was lost with the end of the method then it would be collected by GC