Как глубоко Вы ожидали бы, что неизменность неизменного списка будет?
Я не уверен в том, что вы именно здесь спрашиваете.
CronJob не создает стручки. Это создает рабочие места (которые также управляют), и эти рабочие места создают стручки. Согласно Kubernetes Документация заданий Если заданиями управляет непосредственно контроллер более высокого уровня, например CronJobs, задания могут очищаться с помощью CronJobs на основе указанной политики очистки на основе емкости. Короче говоря, пакеты и задания не будут удалены, пока вы не удалите CronJob. Вы сможете проверить журналы из Pods / Jobs / CronJob. Просто используйте kubctl description
. По умолчанию CronJob хранит историю 3 успешных заданий и только 1 неудавшегося. Вы можете изменить это ограничение в спецификации CronJob с помощью параметров:
spec:
successfulJobsHistoryLimit 10
failedJobsHistoryLimit 0
0 означает, что CronJob не будет хранить историю неудачных заданий
10 означает, что CronJob сохранит историю 10 выполненных заданий [ 118]
Вы не сможете сохранить модуль от невыполненного задания, потому что, если задание не выполняется, оно будет перезапущено до тех пор, пока оно не будет выполнено или не достигнуто значение backoffLimit, указанное в спецификации.
Другой вариант - приостановить CronJob.
kubctl patch cronjob -p '{"spec:"{"suspend":true}}'
Если значение spuspend равно true, CronJob не будет создавать никаких новых заданий или модулей. У вас будет доступ к завершенным блокам и заданиям.
Если ничто из вышеперечисленного не помогло вам, не могли бы вы дать больше информации, чего именно вы ожидаете?
CronJob spec будет полезен.
6 ответов
Это зависит от контекста. В библиотеке общего назначения все, что мы должны предполагать, это то, что список является неизменным. Изменения элементов в списка будут отражены для всех вызывающих абонентов, как прямое следствие возврата одной и той же ссылки каждый раз.
Однако, если это специализированное неизменяемое дерево (или что-то еще), и задокументировано как таковое , то можно ожидать, что элементы списка сами по себе будут неизменными, и это станет спорным вопросом.
Вопрос если не в неизменности списка, а в неизменности содержащихся в нем объектов.
Фактически, если у вас есть ссылочные типы, неизменяемая сущность в списке является ссылкой. Это означает, что ссылка всегда будет одинаковой. Теперь, изменится ли объект, на который указывает ссылка, зависит только от того, что это за объект. Если объект является неизменяемым (например, строки в .NET и Java или все типы значений в .NET), объект не может измениться.
В противном случае объект может измениться, и все другие ссылки на тот же объект будут видеть измененное состояние, поскольку они содержат ссылку на тот же экземпляр. Следовательно, как я писал в начале, это полностью не зависит от списка (и от того, является ли он неизменным или нет).
Этого обычно и следовало ожидать , Список является неизменным, что означает, что вы не можете добавлять или удалять элементы в нем или заменять элементы целиком. Если вы хотите, чтобы эти предметы были неизменными, вы должны позаботиться об этом сами. Этот список определенно не сможет помешать вам изменить состояние объекта, как только вы получите ссылку на него.
Список является неизменным, что означает, что вы не можете добавлять или удалять элементы в нем или заменять элементы целиком. Если вы хотите, чтобы эти предметы были неизменными, вы должны позаботиться об этом сами. Этот список определенно не сможет помешать вам изменить состояние объекта, как только вы получите ссылку на него. Список является неизменным, что означает, что вы не можете добавлять или удалять элементы в нем или заменять элементы целиком. Если вы хотите, чтобы эти предметы были неизменными, вы должны позаботиться об этом сами. Этот список определенно не сможет помешать вам изменить состояние объекта, как только вы получите ссылку на него.Да.
Я не ожидаю, что неизменный список будет клонировать свои объекты, когда я их получу, если только задокументировано, как это делается.
Это действительно зависит от контекста, в котором вы задаете этот вопрос. Любой опытный Java или C # разработчик знает, что технически почти невозможно иметь общую «глубокую неизменность», и поэтому не ожидал бы этого. В C ++ это очень сложная тема , поэтому большинство разработчиков, вероятно, также не ожидают надежной глубокой неизменности. Язык программирования D, с другой стороны, действительно имеет концепцию уровня языка транзитивной неизменности, поэтому программист D, вероятно, ожидал бы этого везде, где это имеет смысл (что довольно часто).
Да, зная Java, для «неизменяемого» списка Я бы не стал ожидать, что T будет неизменным, если T не будет неизменным. Однако разумной реализацией, скажем, List было бы копирование Date каждый раз. Проблема в том, что Дата является изменчивой и может отличаться от других равных Дата с.