Если вы наблюдаете ухудшение производительности при поиске прокси в .NET, есть несколько способов решения проблемы:
- создайте объект
WebProxy с использованием определенного прокси-хоста, вместо того чтобы полагаться на .NET для автоматического обнаружения веб-прокси, что, вероятно, вызывает медлительность, которую вы видите. Это работает в серверных сценариях, например, когда вы можете поместить прокси-сервер в файл конфигурации и забыть об этом. Это не работает в клиентском приложении, где вы не знаете прокси заранее.
- оберните объект
WebProxy в вашей собственной реализации IWebProxy и поместите lock(this){ } вокруг каждого метода и свойства взаимодействия. Сделайте это, если вы не можете знать прокси-сервер заранее, или если вы настроили конкретный прокси-сервер, это не решит вашу проблему.
- Вы всегда можете загрузить справочный источник .NET Framework и просмотреть исходный код реализации WebProxy, чтобы увидеть, действительно ли он безопасен для потоков, несмотря на документацию. Я бы не советовал этот вариант, но я включил его здесь для полноты.
Дополнительная информация:
Интерфейсы (например, IWebProxy) не являются ни потокобезопасными, ни поточно-небезопасными. Это реализации под ними (например, класс WebProxy), которые определяют безопасность потоков.
Тем не менее, WebProxy не является потокобезопасным. Согласно документации MSDN для WebProxy :
Резьба безопасности
Любая общедоступная статика (Shared в Visual
Основные) члены этого типа являются потоками
безопасный. Любые члены экземпляра не являются
гарантированно безопасна для ниток.
Кстати, вышеприведенное (статика является поточно-ориентированной, а методы / свойства экземпляра - нет), как правило, справедливо почти для всех классов в .NET Framework. Поэтому, если вы не видите документацию, в которой говорится, что методы экземпляра являются поточно-ориентированными, вы должны предполагать, что методы / свойства экземпляра не являются поточно-безопасными.