Чи безпечні несинхронізовані статичні методи, якщо вони не змінюють змінні статичного класу?

Мені було цікаво, чи є у вас статичний метод, який не синхронізований, але не змінює жодних статичних змінних, це безпечно для потоків? Що робити, якщо метод створює локальні змінні всередині нього? Наприклад, чи безпечний такий код потоку?

public static String[] makeStringArray( String a, String b ){
    return new String[]{ a, b };
}

Отже, якщо у мене є дві нитки, які постійно і одночасно називають цей метод, один з собаками (скажімо, "великий датчанин" і "бичачий собака"), а інший з котами (скажімо, "персидський" і "сіамський"), коли-небудь я отримаю котів і собак в одному масиві? Або коти і собаки ніколи не будуть знаходитися в одній і тій же позиції методу одночасно?

Цей спосіб на 100% безпечний, він був би навіть якби не був static. Проблема з безпекою потоку виникає, коли вам потрібно обмінюватися даними між потоками - ви повинні подбати про атомність, видимість тощо.

Цей метод працює лише на параметрах, які знаходяться на стеці та посиланнях на незмінні об'єкти на купі. Стек по своїй суті локальний для потоку , тому обмін даними ніколи не відбувається.

Іммунізовані об'єкти ( Stringв даному випадку) також є безпечними для потоків, тому що після їх створення неможливо змінити, і всі потоки бачать однакове значення. З іншого боку, якби метод приймав (змінювався), у Dateвас могли виникнути проблеми. Два потоки можуть одночасно змінювати той самий об’єкт об'єкта, спричиняючи умови перегонів та проблеми із видимістю.

Метод може бути небезпечним для потоків, лише коли він змінює деякий загальний стан. Будь статичний чи ні, не має значення.

Ця функція ідеально захищена від потоку.

Якщо ви подумаєте над цим ... припустимо, що було б, якби це було інакше. Кожна звичайна функція мала б проблеми з ниткою, якщо їх не синхронізувати, тому всі функції API в JDK повинні були бути синхронізовані, оскільки вони потенційно можуть викликатися декількома потоками. А оскільки більшість часу програма використовує деякі API, багатопотокові програми фактично були б неможливі.

Це надто смішно, щоб думати про це, тож тільки для вас: методи не є безпечними, якщо є чітка причина, чому можуть виникнути проблеми. Постарайтеся завжди думати про те, що якби у моїй функції було декілька потоків, і що, якби у вас був крок-налагоджувач і чи буде один крок за іншим просуватися перший ... потім другий потік ... можливо, другий знову ... чи були б проблеми? Якщо ви знайдете його, його не захистіть від потоку.

Будь ласка, майте на увазі, що більшість класів колекції Java 1.5 не є безпечними для потоків, крім тих, де зазначено, як ConcurrentHashMap.

І якщо ви дійсно хочете зануритися в це, уважно подивіться на мінливе ключове слово та ВСІ його побічні ефекти. Погляньте на класи Semaphore () та Lock () та їхніх друзів у java.util.Concurrent. Прочитайте всі документи API навколо класів. Варто вчитися і задовольняти теж.

Вибачте за цю надмірно детальну відповідь.

Використовуйте staticключове слово із синхронізованими статичними методами, щоб змінити статичні дані, що поділяються між потоками. За допомогою staticключового слова всі створені нитки змагатимуться за одну версію методу.

Використання volatileключового слова разом із методами синхронізованого примірника гарантуватиме, що кожен потік має власну копію спільних даних і жодне читання / запис не просочиться між потоками.

Строкові об'єкти, які не змінюються, є ще однією причиною вищезахисного сценарію. Замість цього, якщо використовуються змінні об’єкти (скажімо, makeMutableArray ..), то, безумовно, безпека потоків порушиться.