Часто в приложениях ASP.NET можно встретить код, подобный следующему:
if (Cache["SomeData"]
!= null)
{
string name = ((SomeClass)
Cache["SomeData"]).Name;
//.....
}
Опытный программист, даже если он не страдает паранойей, сразу видит
возможную проблему — NullReferenceException. Все дело в механизме
работы кэша в ASP.NET. В идеальном случае объект, помещенный в кэш, будет
храниться там до перезагрузки приложения, но на практике он может быть удален
между двумя обращениями: во время сборки мусора, если закончилась память
(поскольку кэш использует слабые ссылки WeakReference); другим потоком,
когда нужно перегрузить данные.
Соответственно приведенный код будет работать в 99% случаев, но периодически
в логах будут появляться ошибки, которые практически невозможно повторить. Вот
правильное использование кэша:
SomeClass someClass = Cache["SomeData"]
as SomeClass;
if (someClass !=
null)
{
string name = someClass.Name;
//.....
}
Не теряйте бдительности, они только этого и ждут! (о багах)
Автор: http://kpumuk.info/
Тестирование параллельного программного обеспечения представляет собой более
сложную задачу по сравнению с тестированием последовательной программы. Программист
должен знать о подводных камнях при тестировании параллельного кода, имеющихся
методологиях и инструментарии.
Аннотация. В статье кратко рассматривается архитектура AMD64 компании AMD и ее
реализация EM64T компании Intel. Описаны особенности архитектуры, ее возможности,
достоинства и недостатки.