Недостаточно устройства хранения данных доступно для обработки этой команды в VisualStudio 2008
Я вижу подобные вопросы, которые часто задают, и пока не вижу удовлетворительного ответа.
Ответы, которые я вижу чаще всего, злятся: «Почему тебя это волнует?» ответы. Некоторые люди прилагают много усилий и усилий, чтобы задать вопрос, и тот, кто задает его, кажется глупым.
Некоторые люди ответят на этот вопрос длинным рассуждением о различных видах памяти, выделяемой Java, почему это происходит и какие параметры командной строки вы должны изучить. (редко кто-то получает очень конкретный ответ)
Дело в том, что для небольших утилит Java является бременем памяти в большинстве операционных систем. Чем меньше утилита, тем она более очевидна. Java-разработчики уже давно привыкли иметь дело с этим фактом или игнорировать его.
Причины, по-видимому, ненормального использования памяти многочисленны. Каждый поток получает определенное количество памяти для своего стека. Есть несколько потоков, которые будут запущены независимо от того, насколько проста программа для таких вещей, как очистка мусора, RMI и т. Д. В Windows / 64-битной версии это 1 МБ на поток. Куча классов загружается по умолчанию и все ваши классы. Я уверен, что за кулисами происходит много других вещей.
Java сделала компромиссный выбор, которого нет у других языков. Время загрузки медленнее, чем в большинстве других языков. Начальное требование к памяти выше. Струны, которые они чаще всего используют, поглощают гораздо больше памяти, чем думают большинство людей. Есть бесчисленное множество других. Выгода для многих ситуаций действительно окупается. Нечто подобное Hello World демонстрирует стоимость этих выборов больше всего на свете. Преимущества, такие как легкая многопоточность и почти естественная производительность, действительно не принесут пользы в Hello World.
К сожалению, вы мало что можете сделать, чтобы минимизировать объем памяти, используемой простым приложением. Существуют вышеупомянутые ключи командной строки, и метод проб и ошибок может сократить ваше заявленное использование до уровня ~ 10-15 Мб, я уверен, но эти варианты и время, потраченное на их выяснение, не будут применимы к широкому спектру будущих приложений. Вам придется пройти через тот же процесс снова для следующего приложения. Добавьте графический интерфейс и немного регистрации и другую общую библиотеку или две, и ваш базовый номер будет чертовски быстрым до 60 МБ.
Вы не делаете ничего плохого. Это просто, как все работает в Java. Вы привыкнете к этому. Из-за этого вы будете иногда выбирать другой язык, и это тоже нормально.
4 ответа
В моем случае помогло следующее исправление: http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix
Как заметил Энтони, сообщение об ошибке вводит в заблуждение. Проблема не столько в том, насколько велика ваша сборка, сколько в том, сколько непрерывной памяти доступно.
Проблема, скорее всего, не в размере вашей сборки. Гораздо более вероятно, что что-то внутри Visual Studio фрагментирует память до такой степени, что сборка не может быть завершена. Обычно проблемы такого типа подозреваются
- Слишком много проектов в решении.
- Надстройки сторонних разработчиков
Если у вас более 10 проектов в решении. Попробуйте разбить раствор и посмотрите, поможет ли это.
Если у вас есть какие-либо надстройки сторонних разработчиков, попробуйте отключить их по очереди и посмотреть, исчезнет ли проблема.
Ошибка вводит в заблуждение. Он действительно должен сказать: «Не удалось найти достаточно большое непрерывное пространство в виртуальной памяти для выполнения операции». Со временем выделение и освобождение пространства виртуальной памяти приводит к его фрагментации. Это может привести к ситуациям, когда большой объем памяти не может быть заполнен, несмотря на то, что имеется достаточно общего пространства.
Я думаю, это то, к чему относится ваша «сегментация». Не зная всех подробностей обо всем остальном, что необходимо загрузить, и о другой активности, которая занимает 2-3 часа, трудно сказать, действительно ли это является причиной. Однако я бы не стал относить это к категории маловероятных, на самом деле это наиболее вероятная причина.
Другой причиной этой проблемы может быть использование слишком большого количества типизированных наборов данных через конструктор. или другие типы, которые могут быть созданы с помощью дизайнера, например, множество элементов управления с привязкой к данным во множестве форм. Я представляю, что вы из тех хардкорных программистов, которые не стали бы перетаскивать DS! : D
в отношении вашей проблемы, Богдан, вы пытались воспроизвести проблему без загруженного компонента C ++? Если не можешь, то, может быть, дело в этом. Как вы загружаете компонент? пробовали ли вы другие методы, например, позднее связывание и т. д.? есть ли разница?
Дополнительно: Да, вы правы, другие виновники - это множество элементов управления в форме. Однажды я видел ту же проблему с разработчиком, который импортировал приложение VB6 в .net. у него было буквально сотни форм. Через пару часов у него периодически возникали сбои IDE. Я почти уверен, что это было исчерпание потоков. Возможно, стоит настроить ванильный ящик без загруженных надстроек только для того, чтобы исключить надстройки, но я предполагаю, что вы просто упираетесь в стену с точки зрения комбинированного ограничения VS и ваших спецификаций коробки. Попробуйте запустить 64-разрядную версию Windows Vista и установить дополнительные модули оперативной памяти.