Findbugs идентифицируют многие конкретные случаи потенциально проблемных вопросов бокса. Я связался напрямую с одним примером, но если вы нажмете Ctrl-F для «коробки» на этой странице, вы легко найдете все остальное. Я думаю, что искать конкретные проблемы бокса лучше, чем помечать все сразу. (другими словами, я согласен с 280Z28)
Лучшим инструментом будет тот, который выделяет автоматическую блокировку на путях кода, которые профилировщик доказывает медленными из-за боксов. Принуждение к явной упаковке похоже на предотвращение сборки мусора, потому что в крайнем случае она может быть медленной. Позвольте инструментам делать свою работу - компилятору и языку для выражения реальной проблемы, над которой вы работаете, и профилировщику для выявления проблем с производительностью. Явный бокс неестественен в контексте решения проблемы, потому что он показывает языковые нюансы, которые не являются частью описания решения.
Изменить: уместен ли здесь этот тип комментариев? На самом деле я пытаюсь быть полезным - на самом деле, в прошлом я специально думал об инструменте для идентификации экземпляров кода операции CLI box
на горячих путях.
Если вы используете Eclipse, откройте Preferences и перейдите в Java - Compiler - Errors/Warnings. В разделе Potential programming problems в одной из опций вы можете включить автобоксинг/анбоксинг как предупреждение или ошибку. Этот статический анализ может быть очень полезен при использовании с профилировщиком.
Как отметил 280z28, было бы лучше иметь инструмент, который находил бы случаи автобоксинга/анбоксинга, которые вызываются очень часто и поэтому влияют на производительность. Однако я не знаю такого инструмента.