programmerjava

Используйте лучше Spring Boot - прекрасная тенденция.

Что касается языка, то тут много похожих моментов как и различий.В первую очередь в C# в подавляющем количестве случаев вместо геттеров/сеттеров используются автоматические свойства, также в C# вам предстоит освоить библиотеку TPL(async/await , IAsyncResult , Parallel.Foreach()... etc), которая содержит много синтаксического сахара для создания многопоточных приложений и язык LINQ/PLINQ(Parallel LINQ) который используется для создания запросов к коллекциям, XML-кам и Relational базам данных.В C#, в отличие от java для реализации событий используются делегаты (Event) вместо экземпляров обработчиков, также для реализации lambda выражений в C# используются анонимные методы и тут нет функциональных интерфейсов .Что касается самой платформы .NET - вам предстоит увлекательный путь изучения недр CLR и DLR.

pikabu.ru/profile/alaudo
Почитайте его серию статей "Педиатр-программист", может послужить хорошей мотивацией.

Приложите, пжт, тред дамп (jstack)

Сколько записей в таблице ? Не думали о том, что просто очень долгая выборка ? Посмотрите какой запрос реально выполняется и постройте план запроса. Скорее всего очень большая таблица на которой нету индексов.
Если проблема не в этом, то нужно разбираться что именно происходит уже внутри спринга.

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

Гуглите по словам умным дом.
А дальше по аналогии что-то свое делаете.
geektimes.ru/hub/home_automation

Есть. Гуглите по "Text to speech"

Проверьте кодировку в консоли

gson от google, проще не бывает )
google-gson

Gson gson = new GsonBuilder().create();

String json = gson.toJson(someObject);

SomeObject newso = gson.fromJson(json, SomeObject.class);

Главная фишка высоконагруженных приложений не в выборе технологий, а в архитектуре. Зачастую, узким местом приложения является база данных. Первое, что нужно сделать - это научиться масштабировать данные. Ищем по ключевым словам "шардирование", "репликация".
После того, как данные масштабируются, можно думать о включении кэширующего слоя. Ищем "memcached", "redis".
Если начинает не справляться фронтенд (фронтенд бэкэнда), подключаем балансировщик нагрузки. Как на уровне DNS, так и на уровне отдельных инстансов фронтенда.
Раздаете много статики? CDN вам в помощь.
Много сложных и ресурсоемких вычислений, результат выполнения которых не требует моментального отображения клиенту? Разворачиваем очереди задач и считаем это в фоне.
А уж какую технологию выбрать java или php это Вам виднее. То, что лучше знаете и сможете поддерживать.

Советую почитать ruhighload.com/scale

системы (веб сервис), которая должна выдерживать высокие нагрузки и быть масштабируемой.

достаточно быстро функционал и следовательно посещаемость (по прогнозам - я за это не отвечаю, предо мной просто ставят такую задачу) буду увеличиваться.

Насколько такой вариант будет выдерживать высокие нагрузки?

насколько будет быстро работать, учитывая динамическую типизацию

Это называется преждевременной оптимизацией

Вам не могут ставить требования "сделать производительную и масштабируемую систему". Вам могут сказать соотношение чтения\записи в базу, ожидаемый RPS (стабильный и пиковый), максимальное время ответа на запрос...

Узнать, что будет производительным, а что нет - нужно с помощью профайлера, в крайнем случае - по бенчмаркам. Но никак не задавая вопросы на форумах - просто никто не имеет физической возможности дать объективный ответ на абстрактный вопрос.

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

Если у вас есть опыт с джавой в вебе - делайте на джаве.

Есть опыт с джаваскриптом - делайте на основе веб-сервисов.

У каждого подхода есть плюсы и минусы и обычно они субъективны.

Лучше потратить 2 месяца на прототип и потом - месяц на переписывание, чем сначала 3 месяца думать и делать - а потом понять, что нужно было двигаться в другую сторону.

Описаны ~80% случаев и ваш с вероятностью > 90% попадает именно в эту область.

Самое главное, что в классическом морском бое, если расставлять корабли начиная с 4-х палубного, затем два 3-х палубных, затем три 2-х палубных и четыре однопалубных, то всегда существует расстановка кораблей. Это легко доказуемо. Если вы начнёте с однопалубных, то можете попасть впросак.
Четырёхпалубный ставится выбором направления - горизонталь/вертикаль и выбор начальной клетки - всего 140 вариантов.
Помечаете занятые клетки, клетки вокруг корабля и приступаете к трёхпалубным.
Пробегаете незанятые клетки и пытаетесь проверить возможность поставить корабль по горизонтали или вертикали. Сохраняете в массив все возможные варианты, а затем выбираете один случайным образом.
Повторяете пока не будут расставлены все корабли. Доказательство существования расстановки гарантирует, что у вас всегда будет место, куда поставить корабль.

Я свой вебсокет сервер тестировал с помощью tsung и остался доволен.