.NET по сравнению со сборщиком "мусора" Java
Я думаю, что двусмысленность произошла из-за проблемы чувствительности к регистру в имени столбца искрового фрейма. В последней части схемы я вижу
StructField(adcsm,
ArrayType(StructType(
StructField(tdr,DoubleType,true),
StructField(vdr,DoubleType,true)),true),true)
Итак, внутри plain StructType есть два одинаковых имени structFields (adScm и adscm). Сначала включите чувствительность к регистру искры sql с помощью
sqlContext.sql("set spark.sql.caseSensitive=true")
, а затем разделите два поля. Вот подробности, чтобы решить проблему с учетом регистра решить проблему с учетом регистра . Надеюсь, это поможет вам.
5 ответов
Различие между CLR (.Net) GC и GC JVM, а не самими языками. Оба подвержены изменениям и спецификация их поведения, свободного, чтобы позволить этому быть измененным без него влияющий на правильность программ.
существуют некоторые исторические различия в основном из-за .NET, разрабатываемого с уроками от эволюции Java (и другие основанные на gc платформы). В следующем не предполагают, что .NET, каждый был в некотором роде выше, потому что он включал функциональность с начала, это - просто результат прибытия позже.
А известное публично видимое различие - то, что GC MS выставляет свой характер поколений (с помощью API GC), это, вероятно, останется верным в течение некоторого времени, так как это - очевидный подход для взятия на основе поведения, которое показывает большинство программ: Большинство выделений является чрезвычайно недолгим.
Начальная буква JVM не имела сборщиков "мусора" поколений, хотя эта опция была быстро добавлена. Первые коллекторы поколений, реализованные <забастовкой> Sun Oracle и другие, имели тенденцию быть Mark и Разверткой. Было понято, что подход mark-sweep-compact приведет к намного лучшей местности памяти, выравнивающей по ширине дополнительное копирование наверху. Время выполнения CLR дебютировало с этим поведением.
различие в А между <забастовкой> Sun реализация GC Oracle и Microsoft 'идеал' является одной из конфигурируемости.
<забастовка> Sun обеспечивает огромное число вариантов (в командной строке) к аспектам тонких настроек GC, или переключите его между различными режимами. Много опций имеют-X или-XX для указания на их отсутствие поддержки через различные версии или поставщиков. CLR, в отличие от этого, не обеспечивает рядом ни с какой конфигурируемостью; Ваша единственная реальная опция является использованием сервера или клиентских коллекторов, которые оптимизируют для задержки стихов пропускной способности соответственно.
Активное исследование в стратегиях GC продолжается в обеих компаниях (и в реализациях с открытым исходным кодом), текущие подходы, используемые в новых реализациях GC, на области рая потока (улучшающий местность, и позволяющий набор рая потенциально не вызывают полную паузу), а также подходы pre-tenuring, которые стараются не помещать определенные выделения в поколение рая.
Это должно только добавить к превосходному ответу ShuggyCoUk. GC.NET также использует то, что, знают как "куча" для больших объектов (LOH). CLR предварительно выделяет набор объектов на LOH, и выделенные объекты всего пользователя по крайней мере 85 000 байтов выделяются на LOH также. Кроме того, double[] из 1 000 элементов или больше выделяется на LOH также из-за некоторой внутренней оптимизации.
LOH обрабатывается по-другому, чем "куча" поколений различными способами:
- Это только убрано во время полного, собираются, и это никогда не уплотняется как "куча" поколений.
- Выделение от LOH сделано с помощью бесплатного списка во многом как
malloc, обрабатывается во времени выполнения C, тогда как выделения от "кучи" поколений по существу сделаны, просто переместив указатель в поколении 0.
я не знаю, имеет ли JVM что-то подобное, но это - важная информация о том, как память обрабатывается в.NET так, надо надеяться, Вы находите это полезным.
Если я вспоминаю правильно, JVM не освобождает освобожденную память назад к операционной системе, как CLR делает.
Java 5 ввел много изменений в его алгоритмы GC.
я не знаток C#, но эти две статьи намекают мне, что и развились далеко от простой метки и развертки и к более новым моделям поколения:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html http://www.csharphelp.com/archives2/archive297.html
Я нашел это:
В версии платформ 1.4.2 J2SE было четыре сборщика "мусора", из которых можно выбрать, но без явного выбора пользователем всегда выбирался последовательный сборщик "мусора". В версии 5.0 выбор коллектора основан на классе машины, на которой запущено приложение.
здесь и это
Также так же, как JVM справляется, разрушение объектов так также делает CLR через Mark и Компактный алгоритм сборки "мусора"
, я надеюсь, что это помогает...