Зачем это вообще нужно?

Вопрос по задаче

Обсуждается

Добрый день!

TestedThread commonThread = new TestedThread(handler); //тут создается обьект поток

Thread threadA = new Thread(commonThread, "Нить 1"); тут для чего то в конструктор потока пробрасывается обьект потока и ее название
Thread threadB = new Thread(commonThread, "Нить 2");

Обьясните пжлста зачем вообще нужно в конструктор Thread подавать сслылку на объект commonThread ? Что это дает? Какое практическое значение? Для чего так делается? Спасибо.

Комментарии (7)

популярные
новые
старые

Для того, чтобы оставить комментарий Вы должны авторизоваться

Waumok Backend Developer

25 апреля 2021, 00:14

Чтобы прочитав про "Thread.UncaughtExceptionHandler" ты все равно не сразу понял что не так)) конкретно в этой задаче), т.е. - при создании нити, ты создаешь нить и передашь туда обьект (commonThread) наследника нити (он же имплементирует раннэйбл) но его конструктор в котором есть setUncaughtExceptionHandler(handler), не связан с методом ран который будет использоваться вот так

TestedThread commonThread = new TestedThread(handler); //тут создается обьект поток
commonThread.start();

то у этого потока все бы отработалокак и задумывалось) а если рассматривать другие "адекватные" примеры то это потоки ввода и вывода, когда в конструктор передается другой поток,(промежуточный) или как и описал Андрей саму идею👇(почему это возможно) но не в этом примере(задаче)

Sergey April

Уровень 19

27 апреля 2021, 13:54

Все равно не понял. Вот я же могу написать так: Thread threadB = new Thread(); - и все будет нормально, создаться обьект Thread. И я не понимаю просто для чего мне в него тогда пихать ссылку на другой поток? Ну я понимаю еще пробросить "название" для него, а что даcт пробрасывание именно ссылки на другой поток? Что при этом произойдет? Какой то конструктор сработает? и какой результат его работы будет - вот это не понятно.

Waumok Backend Developer

27 апреля 2021, 15:24

Смотри это не ссылка на другой поток - это объект который реализует интерфейс раннейбл нить Thread тоже реализует интерфейс раннэйбл мне кажется у тебя проблема с интерфейсами а не нитями например тебе нужен класс "который ходит на сервер и проверяет обновления 1 раз в час" у тебя уже есть абстрактный класс. который тебе подходит и в котором надо чуть изменить, пару методов... ты наследуешься от абстрактного класса , но теперь ты не можешь наследоваться от Thread.. у твоего класса только один вариант имплементировать интерфейс раннейбл (наследоваться можно от нескольких интерфейсов) если ты создал объект от класса который наследуется, от Thread, ты не сможешь отнаследовать его от кого то еще... а интерфейс ты можешь присобачить к чему угодно, и сделать из него болванку - заготовку которую передашь в конструктор нити Thread Thread - все равно что в объекте, ему главное чтобы был метод RUN (быть имплементатором раннейбла), а вот уже сам метод ран, сможет использовать поля и методы которые ты заложил в заготовку, и будет вести себя как ты хочешь (котом, собакой, машиной т. д.)

Waumok Backend Developer

27 апреля 2021, 15:39

class Thread {
    private string name;
    private Runnable object;

    Thread(Runnable r, String name) {
        this.object = r;
        this.name = name;
    }

    void start() {
        r.run();
    }
}

то что я написал полная охинея, но методы потоков Нативные, они написаны на не на джаве,а на С++ или еще чем по круче.... как они работают, нам знать не нужно, но судя по результату который мы получаем, можно структуру представлять так, нет ничего плохого Б просто помнить что это образно

Andrew Nikitin

Уровень 18

25 апреля 2021, 00:10

если коротко то для сложности ) а если упростить и добавить в мейн commonThread.interrupt(); а нити закоментить то увидишь что все ок работает -но тока это будет поток Thread-0 (кстати main всегда мейн называется без цифорки) а если запустить и тормознуть Нити 1 и 2 это уже будет еще два потока (с учетом мейн и вот подсказывают сборщика мусора - всего их уже 5 получается - но несуть) короч когда ты создаешь Нити1 и 2(по сути 3 и4 потоки) - методом всовывания их аргументом в ТРЕАД- это новые нити и они не в курсе про конструктор КоммонТреад с обработкой runtime и им надо вручную добавить обработку runtime - либо в main Thread.setDefaultUncaughtExceptionHandler(handler); //установиф дефолт для вообще всех нитей либо в main threadA.setUncaughtExceptionHandler(handler); //каждой в отдельности threadB.setUncaughtExceptionHandler(handler); либо в run currentThread().setUncaughtExceptionHandler(handler); наверно есть еще 100500 способов но пока мы всетаки учимся азам таксказать

Waumok Backend Developer

25 апреля 2021, 01:00

про поля и задать поведение методу run() зря удалили)) не лишнее для понимания всего 5, там обычно гарбеч-колектор тусуется еще)) или прям в методе run() прописать по currentThread().setUncaughtExceptionHandler(handler)

Andrew Nikitin

Уровень 18

26 апреля 2021, 15:10

ну и вот мой теоретический взгляд на "действительно зачем" : типо тут такой расклад: commonThread - это нубский поток и так их создавать для пацанов зазорно - короче это просто экземпляр описания в2ух словах один из способов сделать пацанский поток такой: 1 написать "нубский" класс\описание потока с методом run - class TestedThread - с "описанием вариантов состояний экземпляров" 2 создать "нубские" экземпляры "описания" потока - экземплр commonThread - и "выбрать состояния аргументами" 3.XXX - создать полное рабочее описание работы потока в JVM - class Thread - уже сделано за нас - "с описанием вариантов состояний потока и всего такого чего надо и ненадо " 4 создать экземпляры потоков - экземплр threadA и B - и "выбрать состояния потоков аргументами" 5 оживить\запустить суперпоток ) - .start() для данного случая -для понимания: поток будет создаваться созданием экземпляра класса Thread (который мы не корректируем в целях безопасности "вселенной и дельфинов") свое описание потока мы передаем в него в качесве аргумента - но не сам класс\описание а экземпляр описания (с определенным состоянием - набором полей итд ) так просто удобнее и безопаснее - можно на основе одного описания\класса создавать разные экземпляры описаний и потом еще более разные потоки на основе Thread по вопросу TestedThread итак наследует Thread - ну типо походу так как впримере более лутчше ну и самбы с удовольствием послушал бы комментарии магистров к чему все эти сложности )