Эффективное количество потоков

Я думаю, что что-то в этом роде сработает, если предположить, что названия перечислений следуют схожему образцу:

public D Map<D, S>(S enumValue, D defaultValue)
    {

        D se = defaultValue; 
        string n = Enum.GetName(typeof(S), enumValue);

        string[] s = Enum.GetNames(typeof(S));
        string[] d = Enum.GetNames(typeof(D));
        foreach (var v in d)
        {
            if (n.Substring(1, n.Length - 1) == v.Substring(1, v.Length - 1))
            {
                se = (D)Enum.Parse(typeof(D), v);
                break;
            }
        }
        return se;
    }

Варианты 2 будут состоять в том, чтобы создать словарь ints для отображения..

DestEnum de = DestEnum.DNone;
        SourceEnum se = SourceEnum.SA;
        Dictionary<int, int> maps = new Dictionary<int, int>();
        maps.Add((int)SourceEnum.SNone, (int)DestEnum.DNone);
        maps.Add((int)SourceEnum.SAB, (int)(DestEnum.DA | DestEnum.DB));
        maps.Add((int)SourceEnum.SA, (int)DestEnum.DA);
        de = (DestEnum)maps[(int)se];

Есть разница, когда вы подкласс Foo:

public class Bar extends Foo {

}

затем попытаться в другом пакете:

new Bar().getIntProperty ()

Он будет компилировать во втором из ваших примеров (все методы открытые), но не в первом (все методы доступ по умолчанию)

Универсального ответа на этот вопрос на самом деле нет. Количество порождаемых потоков зависит от того, сколько задач вы выполняете, как они взаимодействуют и как вы разрабатываете приложение. У меня были чрезвычайно большие приложения, которые имеют только один поток, который работает нормально. С другой стороны, у меня также были небольшие приложения, которые предписывали несколько потоков для производительности.

(Извините за любые проблемы с орфографией/форматированием, я ввел это без телефона)

Книга Java Concurrency in Practice содержит приблизительную формулу для определения размера пула потоков для сохранения определенной загрузки ЦП:

N = количество ЦП

U = целевая загрузка ЦП, 0 < = U < = 1

W/C = отношение времени ожидания для вычисления время

Оптимальный размер пула (количество потоков) для хранения процессоров в требуемое использование:

PoolSize = N * U * (1 + (W/C))

Это только для загрузки ЦП.

Вы можете получить доступные процессоры с помощью Runtime.getRuntime () .availureProcessors ()

Я не думаю, что на это есть окончательный ответ. Я бы просто предложил попробовать ваше приложение с разным количеством потоков и увидеть, что работает лучше всего. Одним из мест для запуска будет один поток больше, чем количество потоков процессора в вашем оборудовании, например, если у вас есть двухъядерный процессор с одним потоком на ядро, то используйте 3 потока.

Я обнаружил, что лучший способ справиться с этим - не использовать потоки напрямую, а использовать среду Executor. Вы можете экспериментировать с различными конфигурациями, но я обнаружил, что мне нравится CallerRunsPolicy.

Книга Java Concurrency in Practice дает приблизительную формулу для определения размера пула потоков, чтобы ваши процессоры были привязаны к определенному использованию:

N = количество ЦП

U = целевая загрузка ЦП, 0 <= U <= 1

W / C = отношение времени ожидания к вычислению времени

Оптимальный размер пула (количество потоков) для сохранения процессоров с желаемой загрузкой:

PoolSize = N * U * (1 + (W / C))

Это это только для загрузки процессора.

Вы можете получить доступные процессоры с помощью Runtime.getRuntime (). AvailableProcessors ()

Производительность - далеко не единственная причина использования потоков.

По сути, любая многопоточная программа может быть смоделирована с помощью одного более сложного потока, поэтому на самом деле потоки упрощают ваш код, а не обязательно ускоряют его.

Тем не менее, если ваше приложение может использовать несколько ядер или несколько головок дисков, работающих одновременно, потоки могут упростить использование этого. В этом случае вам, вероятно, не понадобится больше потоков, чем у вас есть отдельные ядра или головки, потому что переключение процессов имеет определенную стоимость.