Я вот чё подумал... 
Может быть я недооцениваю потоки в Java?

Например пусть в одном приложении у меня есть поток Keeper и поток Utilizateur, и в одном из них произошёл непоправивый сбой, то JVM мне остановит только поток-виновник сбоя или прибъёт всё приложение?

Добавлено через 2 минуты и 51 секунду

Предстаьте себе, что вы меняете значения трёх миллионов объектов не напрямую, а используя сериализацию/десериализацию (RMI) :о) Насколько это будет медленнее?

Только поток вызвывший сбой. Плюс ты можешь зарегистрировать своего обработчика на это событие.

Добавлено через 5 минут и 16 секунд

Внутри одной JVM можно использовать статические поля/методы.

Тогда это выход.

Если сбой в одном потоке не вызывает снятия всего приложения исполняющей JVM, то я нашёл ответ на свой вопрос.

Всем участникам спасибо за возню со мной, косноязычным :о)
Теперь бы ещё понять, как отловить переполнение.... Но для этого я открыл другую тему.

Ещё раз спасибо, ребята :о)

Если сбой произошел по вине данных, то они успешно положат и второй поток.
Если же, допустим, засбоит JVM, то приложение также умрёт. Поэтому я не понимаю смысл подобной избыточности - она не даёт особых прибылей.

Данные не могут положить поток. Поток может положить неправильный метод.

Не положат они второй поток, потому что второй поток не делает с ними те же операции что и первый :о)

Прибыль получается, что в случае сбоя второго потока, нам нужно его перезапустить на уже готовые, существующие объекты. А в случае однопоточного приложения нам придётся переиничивать все объекты, а это занимает бешеное время, в моём приложении 15 минут.

  

А что помешает ему после перезапуска, на тех же самых данных снова лечь?  

А он ведь не с того же места начнёт выполнение, а значит вызовет другой метод или тот же метод с другим объектом, так что может вообще повторной ошибки не произойти :о)))

Грубо говоря, вот у нас любое  оконное приложение состоит из трёх потоков.
1. UI
2. Внутренняя логика
3. Ввод-вывод всякий, кроме UI.

В таком приложении нужно просто добавить поток Keeper, который всегда будет работать, ничего не делая, кроме ожидания остановки одного из первых трёх потоков по ошибке. В случае остановки одного из указанных потоков, Keeper его перезапускает. При этом данные приложения сохранятся. :о)

что значит - неправильный метод?

неправильный метод, это такой метод, который делает не то, что написано в спецификации этого метода, например закоден с ошибкой в алгоритме, или кодер ошибся с приоритетом операций и скобки не там стоят... 

Так его надо переписывать, значит, а не в двух потоках запускать. А если у тебя есть два неправильных метода, и они выполнятся в двух потоках с интервалом, допустим, в три минуты?

to Prol, Вы какие ошибки имеите в виду? Какие данные? В двух словах, какой алгоритм?

Просто опять грубо: Возникает у Вас ошибка деления на 0 в алгоритме, алгоритм завершается, как-либо? Ну допустим вылетает. Данные сохранились. И опять так же обрабатываются. Алгоритм опять вылетает.. Что дальше?!

ps. Горе от ума?!   

Значит я подготавливаю исправленный вариант, оцениваю, требуется ли перезапуск и пишу емерженси рекваест, в котором указываю причиной требования - мои ошибки в коде и несу его начальству, начальство снимает с меня премию месячную, аппрувит рикваест, я перезапускаю приложение внепланово.

Добавлено через 3 минуты и 54 секунды

Ну ето не самая частая ошибка, в прошлом году три раза вылетала. Ничего страшного, перезапустился тут-же, а там другие проверки не пропустили до этого места, а потом корку копал, искал откуда он проскочил, етот делений на ноль.

Печально, но ничего не понял, кроме того, что лучше бы таких ошибок не возникало.
Ну это и так понятно.

Ну возникла идея. А почему бы тогда всё-таки данные и обработчик вообще разъединить?
Чтобы перезапускать надо было только обработчик, если он сбоит?

Так я так и делаю сейчас. У меня Кипер и Утилизатор два разных приложения в контексте ОС. Кипер хранит данные и работает ну вот последний аптайм 170 суток. А Утилизатор с этими данными работает аптайм уже две недели со времени последнего перезапуска.