/rf/ - Убежище

Доска с ОП-модерацией
Имя
Email
Тема
Комментарий
Файл
Пaроль (Для удаления файлов.)

File: 1720457076601.png (347.82 KB, 444x444, Untitled.png)

 No.48219

Тут будет бложик ни о чём конкретном, о пустяках, о самых различных предметах.

 No.48235

File: 1720466972105.png (26.03 KB, 420x268, Screenshot 2024-07-08 2137….png)

Практически единственное и самое главное отличие класса ArrayList от класса Vector в том, он является несинхронизированным. То же можно сказать и о HashTable -> HashMap(?).
В основе идеи изменения классов таким образом, чтобы они были несинхронизированными, лежит проблема цены синхронизации.
Сейчас в JVM время, требуемое для захвата блокировок при синхронизации пренебрежимо мало, но излишняя низкоуровневая синхронизация всё ещё замедляет работу приложений.
API коллекций передает коду приложения возможность синхронизировать доступ к коллекциям по мере
необходимости и предоставляет специальную функциональность «быстрого отказа», которая помогает обнаруживать одновременные обращения и вы�давать исключения.
https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
https://www.geeksforgeeks.org/fail-fast-fail-safe-iterators-java/
Fail-fast iterators :
These iterators throw ConcurrentModificationException if a collection is modified while iterating over it.
They use original collection to traverse over the elements of the collection.
These iterators don’t require extra memory.
Ex : Iterators returned by ArrayList, Vector, HashMap.

Вот зачем нам нужен Class CopyOnWriteArrayList<E> — его итератор создает снэпшот с коллекции и работает с ней.
Когда это может быть полезно?
Когда нам нужна потокобезопасность, у нас небольшое количество операций поизменению элементов и большое по их чтению.
https://docs.oracle.com/javase%2F8%2Fdocs%2Fapi%2F%2F/java/util/concurrent/CopyOnWriteArrayList.html
https://youtu.be/QiO_-GXLP-8
we can iterate over the list in a safe way, even when concurrent modification is happening.
_
https://docs.oracle.com/javase%2F8%2Fdocs%2Fapi%2F%2F/java/util/concurrent/package-summary.html#MemoryVisibility
https://youtu.be/QiO_-GXLP-8

 No.48279

File: 1720526402900-0.png (38 KB, 1195x511, ClipboardImage.png)

File: 1720526402900-1.png (15.5 KB, 605x165, ClipboardImage.png)

File: 1720526402900-2.png (15.5 KB, 605x165, ClipboardImage.png)

File: 1720526402900-3.png (88.16 KB, 1200x877, ClipboardImage.png)

Have a range of 1000-01-01 00:00:00 to 9999-12-31 23:59:59
Values outside the range may work - but only values within the range are guaranteed to work.

https://mariadb.com/kb/en/constraint/

Потоки потребляют память; у каждого потока есть собственный стек
для локальных переменных, а переключение между работающими потоками
(переключение контекста) создает дополнительную нагрузку на процессор.
Хотя потоки относительно легковесны (теоретически на большом сервере мо�гут работать сотни и тысячи потоков), но все-таки в какой-то момент времени
ресурсы, потребляемые потоками, могут вступить в противоречие с той целью,
ради которой запущено так много потоков. Часто это противоречие возникает
всего с несколькими десятками потоков. А решение с созданием отдельного
потока для каждого клиента не всегда масштабируется.
В таких ситуациях часто создаются «пулы потоков»: фиксированный набор
потоков извлекает задачи из очереди и возвращается за новыми задачами
после их завершения. Такое повторное использование потоков обеспечивает стабильную масштабируемость, но раньше его было трудно эффективно реализовать на Java-серверах, потому что потоковый ввод-вывод (для таких
источников, как сокеты) не в полной мере поддерживал неблокирующие
операции. NIO поддерживает асинхронные каналы: неблокирующие
операции чтения и записи, а также возможность проверки готовности потоков
к перемещению данных. Каналы также могут асинхронно закрываться, что
позволяет потокам корректно работать с ними.
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html
Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.

Какие важные средства многопоточности и станадртных реализаций паттернов можно выделить:

Реализации коллекций с поддержкой потоков в concurrent:
-Queue с ограниченным по времени ожиданием и блокировкой, неблокирующие, оптимизированные для параллельного доступа реализации интерфейсов Queue, Map.
-List, Set "copy on write" - эффективны с доступом "почти всегда для чтения" (>>48235).

Executor, future, callable:
-Запускает задачи (включая объекты Runnable).
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executor.html
-Future,callable
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Callable.html
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html
A Future represents the result of an asynchronous computation. Methods are provided to check if the computation is complete, to wait for its completion, and to retrieve the result of the computation. The result can only be retrieved using method get when the computation has completed, blocking if necessary until it is ready.

java.util.concurrent.locks:
-lock
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Lock.html
-condition
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html
Condition factors out the Object monitor methods (wait, notify and notifyAll) into distinct objects to give the effect of having multiple wait-sets per object, by combining them with the use of arbitrary Lock implementations. Where a Lock replaces the use of synchronized methods and statements, a Condition replaces the use of the Object monitor methods.

Высокоуровневые конструкции (классы, реализущие паттерны синхронизации):
CyclicBarrier, CountDownLatch, Semaphore
и Exchanger. (примеры на пикр4)

Атомики:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html

https://youtu.be/tAbe5m7RjWE

 No.48616

А почему Java?



[Назад][Наверх] Catalog [Post a Reply]
удалить пост [ ]