Статьи

Общие Java-мифы

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

Миф 1) System.exit (0) предотвращает окончательный вызов

Почему этот код

01
02
03
04
05
06
07
08
09
10
11
12
System.setSecurityManager(new SecurityManager() {
       @Override
       public void checkExit(int status) {
           throw new ThreadDeath();
       }
   });
 
   try {
       System.exit(0);
   } finally {
       System.out.println("In the finally block");
   }

Распечатать

1
In the finally block

и почему он не печатает трассировку стека?

Миф 2) Строка str = «Привет»; В этом коде str является объектом String.

В отличие от C ++, все переменные являются либо примитивами, либо ссылками. переменные не могут быть объектами. Это означает, что когда у вас есть выражение вроде

1
2
3
4
5
String str = "Hello";
String text = "Bye";
 
str == text; // compares two references, not their contents.
str = text; // assign the reference text has to str.

Во многих случаях разница невелика, но это вызывает путаницу с такими строками.

1
2
3
final StringBuilder sb = new StringBuidler();
   sb.append("Hello"); // The reference sb is final, not the instance it references.
   method(sb); // method can alter the instance, but it cannot change the reference.

Миф 3) У Java есть утечки памяти, как их понимает разработчик C ++.

В Википедии утечка памяти

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

Тем не менее, в Java, объекты всегда доступны, и это те объекты, которые не сильно доступны, которые убраны. Термин для утечки памяти в Java означает; любое нежелательное увеличение остаточной памяти, обычно из-за того, что ресурсы записываются в коллекции, когда они больше не нужны.

Миф 4) Многопоточность — это сложно

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

Миф 5) Мне не нужно понимать относительную производительность различных операций, если я забочусь о производительности.

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

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

Миф 6) Случайное число всегда выглядит случайным

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

Миф 7) Следует избегать с плавающей точкой, потому что она имеет случайные ошибки.

Плавающая точка будет выдавать одну и ту же ошибку для одной и той же операции каждый раз. Ошибка предсказуема и, следовательно, управляема. Если вы знаете, что делаете, и придерживаетесь простых правил, таких как округление результатов, код с плавающей запятой не менее подвержен ошибкам, чем использование BigDecimal, за исключением того, что он легче для чтения и примерно в 100 раз быстрее (и не создает мусора).

Миф 8) Часовые пояса вне времени

Частой причиной путаницы является тот факт, что со временем часовые пояса меняются. Это означает, что в эпоху Европа / Лондон было 1970/1/1 01:00, а не 00:00, почему? Между 1968 и 1970 годами Лондон находился в летнее время в течение 2,5 лет.

Многие другие часовые пояса изменились за последние несколько лет. В Москве было GMT + 3, а сейчас GMT + 3 (с 27 марта 2011 года). Если вы проверите время в 2010 году, вы должны увидеть GMT + 3, а не +4.

Для вас это звучит странно,

  • В Швеции 1721 года они имели 30 февраля
  • В Англии в 1751 году первым днем ​​года было 25 марта, и с Францией была разница в 11 дней.
  • Когда США приняли григорианский календарь, он сделал это ретроспективно, поэтому записанные даты в течение нескольких сотен лет могут относиться к любому календарю. (Часто обе даты приведены для минимизации путаницы). Например, день рождения Джорджа Вашингтона изменился с 11 февраля 1731 года на 22 февраля 1732 года.

Миф 9) Когда вы читаете энергонезависимое значение в одном потоке, вы в конечном итоге видите обновленное значение.

Это произошло дважды за последний день в StackOverflow. По сути, JIT может оптимизировать код, в котором он содержит энергонезависимые поля, которые поток не меняет. После того, как код скомпилирован (вы можете увидеть это с -XX: + PrintCompilation ), он может никогда не увидеть изменения, которые вы выполните позже в другом потоке. Добавление случайного синхронизированного блока или оператора print может замедлить процесс или спутать JIT, и он не выполняет оптимизацию (ни по времени, ни вообще).

Миф 10) Большая часть контента по вопросам интервью на Java является точной.

Очень большой процент вопросов о собеседовании на Java либо устарел (более десяти лет и не относится к какой-либо современной версии Java), либо вводит в заблуждение, либо просто неверен. К сожалению, они собираются и перерабатываются без проверки ответов.
Я бы посмотрел ответы на StackOverflow, так как они лучше рассмотрены. Прежде всего, избегайте таких сайтов, как Rose India, которая имеет удивительно неизменно низкое качество. Если вы чувствуете себя педантичным, попробуйте найти, сколько орфографических ошибок (в названиях классов и технических терминах) и мифов вы можете найти в одном посте. Часть проблемы в том, что нет эффективного способа предоставить обратную связь и исправить это.
Ссылка: Общие Java-мифы от нашего партнера JCG Питера Лоури из блога Vanilla Java .