скачать книгу бесплатно
Многопоточность обычно требует фундаментальных изменений в стратегии проектирования.
Предусмотреть перебивание потоками друг друга (требуется знание обработки байт-кода и атомарных операций модели памяти).
Многопоточные архитектуры должны отделяться от основного кода.
Код реализации многопоточности имеет собственный цикл разработки, модификации и настройки.
При написании кода многопоточности возникают специфические сложности.
Предусмотреть обработку обращений к общему объекту.
Инкапсулировать данные: жестко ограничить доступ и область видимости общих данных.
Вместо использования общего объекта каждому потоку можно предоставить копию.
Использовать синхронизацию.
Потоки должны быть как можно более независимы.
Постараться разбить данные на независимые подмножества, с которыми могут работать независимые потоки (возможно, на разных процессорах).
Использовать потоково-безопасные коллекции.
Использовать неблокирующие решения.
Изучать доступные классы на предмет потоково-безопасности.
Модели логического разбиения поведения программы при многопоточности:
– производители-потребители: потоки-производители создают задания и помещают в буфер или очередь. Потоки-потребители извлекают задания из очереди и выполняют их. Производители перед записью дожидаются появления свободного места в очереди, а потребители дожидаются появления заданий в очереди. Производитель записывает задание и сигнализирует о том, что очередь непуста. Потребитель читает задание и сигнализирует о том, что очередь не заполнена. Обе стороны готовы ждать оповещения о возможности продолжения работы;
– модель читатели-писатели: писатели пишут в общий ресурс, который считывают читатели. Писатель может блокировать читателей. Нужно найти баланс между потребностями читателей и писателей, чтобы обеспечить правильный режим работы, нормальную производительность и избежать зависания;
– модель обедающих философов: за круглым столом сидят философы-потоки и думают, в центре – тарелка еды. Каждому философу для еды доступно 2 вилки-ресурсы – по 1 от соседей. Когда философ проголодается – берет вилки, поел – кладет обратно. Сложности проектирования – взаимные блокировки, обратные блокировки, падение производительности и эффективность работы.
Изучать базовые алгоритмы, разбираться в решениях.
Избегать использования нескольких методов одного совместно используемого объекта.
Избегать зависимостей между синхронизированными методами.
Или использовать 3 стандартных решения:
– блокировка на стороне клиента;
– блокировка на стороне сервера;
– адаптирующий сервер.
Код не должен перегружаться лишними синхронизированными объектами, так как блокировки создают задержки и увеличивают затраты ресурсов.
Синхронизированные секции должны иметь минимальные размеры.
Корректное завершение не может быть бесконечным ожиданием потока.
Реализовать логическую изоляцию конфигураций многопоточного кода.
Протестировать программу с количеством потоков, превышающим число процессоров.
Применять инструментовку кода для повышения вероятности сбоев.
Сначала отлаживать основной код.
Не игнорировать системные ошибки, считая их случайными разовыми сбоями.
Убедиться, что сам код работает вне многопоточного контекста, созданием POJO-объектов, вызываемых из потоков.
Реализовать многопоточный код так, чтобы он мог выполняться в различных конфигурациях: с разным числом потоков, тестовых заменителей, времени работы тестов, количеством повторов тестов.
Найти средства измерения производительсноти системы в разных конфигурациях.
Реализовать систему так, чтобы количество программных потоков могло легко изменяться, в том числе во время работы системы, в том числе с автоматическим регулированием количества потоков.
JVM не гарантирует вытесняющей многопоточности.
Протестировать систему во всех средах, которые могут использоваться для ее развертывания, начиная с ранней стадии.
Заставить поток исполняться по разным путям в тесте методами object. wait (), object.sleep (), object. yield (), object.priority () – инструментовка кода.
Автоматическая инструментовка с использованием Aspect-Oriented Framework, CGLIB, ASM, ConTest.
Суть тестирования – сломать предсказуемость пути выполнения.
Использовать стратегию случайного выбора пути выполнения для выявления ошибок.
Типичные источники многопоточных ошибок: работа с общими данными из нескольких потоков, использование пула общих ресурсов.
Использовать длительное тестирование многопоточного кода перед включением в систему.
Программирование ближе к ремеслу, чем к науке.
Спасать положение нужно именно сейчас.
Во время переработки кода не добавлять в программу новые возможности.
Предусмотреть, в каких местах будет появляться новый код.
Множество разных типов со сходными методами – причина выделить класс.
TDD: не вносить в систему изменения, нарушающие работоспособность системы.
Добавление теста или класса ничего не нарушит.
Удалять бесполезные функциии.
Тесты всегда должны хотя бы запускаться.
Прочитать последовательное очищение.
Переработка кода напоминает кубик Рубика.
Важный аспект хорошей архитектуры – логическое разбиение кода.
Плохой код тянет группу ко дну.
Открытый код требует смелости и доброй воли.
Полезные высказывания из книги «Отладка приложений для Microsoft. Net» Джона Роббинса
В разделе приведены цитаты из [4].
Большинство команд тратит в среднем 50% цикла разработки на отладку.
Отладка требует специального обучения.
Для того чтобы эффективно отлаживать любую технологию, нужно знать намного больше, чем может дать книга, сфокусированная на конкретной технологии.
Книги по программированию бывают посвящены менеджменту и технологиям.
Основные программы отладки. NET: VisualStudio и WinDBG.
Разработчики должны использовать только учетные записи, обладающие привилегиями пользователя.
john@wintellect.com – автор.
Ошибки помогают понять работу вещей.
Ошибки в ПО могут привести к смене работы.
Ошибка – все что угодно, что заставляет пользователя страдать.
Категории ошибок: аварии и зависания, низкая производительность и масштабируемость, неверные результаты, нарушения безопасности, противоречивые пользовательские интерфейсы, неудовлетворенные ожидания.
Нельзя выпускать на рынок продукт с авариями и зависаниями.
Windows Error Reporting.
Пользователи иногда перестают пользоваться продуктом из-за одного неудачного опыта.
С точки зрения управления проектами главное – уделить внимание производительности.
Должны быть заданы конкретные цифры, связанные с производительностью.
Не делать продукт более медленным, чем его предыдущая версия.
Тестировать приложения по сценариям, наиболее точно отражающим реальный мир.
Наборы данных из реального мира брать у клиентов.
Реальные данные должны быть модифицированы – удалена конфиденциальная информация.
Писать код проверки результатов.
Выставлять требования к производительности, масштабируемости, безопасности.
Проводить тестирование безопасности и моделирование угроз.
Интерфейс приложения не должен противоречить интерфейсу среды.
Приложение не противоречит сочетаниям клавиш среды запуска.
«Designing web usability: the practice of simplicity» Якоб Нильсен.
«Don’t make me think! A common sense approach to web usability» Стивен Круг.
cnn.com – лучший пример дизайна.
joelonsoftware.com/articles.
Все члены команды должны посещать клиентов и наблюдать за использованием ПО.
Никогда не обещать того, чего не сможете дать, и всегда реализовывать обещанное.
Категории причин появления ошибок: слишком короткие или нереальные сроки выполнения; подход «сначала код, потом подумаем»; неправильное понимание требований; невежество разработчиков или недостаточное качество обучения; наплевательское отношение к работе.
Учитывать время на обучение, необходимое для того, чтобы реализовать какую-либо функцию.
Команда разработчиков должна быть истинным хозяином своего расписания, определять реалистичные даты выпуска за счет сокращения числа функций.
Перед написанием кода хорошенько подумать об архитектуре.
Продумать все «что, если».
Определить все риски проекта.
Члены команды не должны отдавать контроль над конструированием системы не умеющим это делать людям.
Не начинать сразу кодировать при получении плана.
