朝の最初のことは、PC(Windows XP)をオンにしてEclipseを起動した直後に、スプラッシュスクリーンを表示してフリーズするだけです。約20分後、ロードするワークスペースを尋ねられます。
この問題は、3.5および3.6 Eclipseで発生していました。 3.6 Eclipseのインストールでは、標準PDEインストール+ Googleプラグイン(GWT開発用)+ Subclipseのみがあります。
ワークスペースを要求するように構成されているため、ワークスペースまたはプロジェクトに関連していないことがわかります。
これをインストールする前に問題はなかったので、Googleプラグインを疑いますが、検索して、同様の問題を報告している人に出会ったことはありません。
朝にマシンのスイッチを入れた直後に、これは一度だけです。この後、正常に起動します-通常は数秒で。
何をしているのでしょうか?それが何をしているのかを知るにはどうすればよいですか?
問題が見つかりました。 Google GWTプラグインは自動的にクリーンアップせず、多くのファイルをTempフォルダー(C:\ Documents and Settings {username}\Local Settings\Temp on XP)に残します。ここには100,000以上のファイルと数千のフォルダーがありました-それらの99%以上はGoogle GWTプラグインによるものです。これらを削除すると、Eclipseは20分ではなく数秒で起動します。さらに、マシン全体が通常よりスムーズに動作します。
@CharlesBが投稿したリンクは正しい方向に私を導きましたが、あなたは.snap
ファイルは次の場所にあります。
[Workspace Directory]/.metadata/.plugins/org.Eclipse.core.resources/.snap
(.metadata
ディレクトリは非表示です。
多分 このブログ投稿 が役立つかもしれません:
ワークスペースディレクトリで、次の手順を実行します。
- cd .metadata/.plugins
- mv org.Eclipse.core.resources org.Eclipse.core.resources.bak
- Eclipseを起動します。 (プロジェクトが見つからないため、エラーメッセージまたは空のワークスペースが表示されます。)
- 開いているすべてのエディタータブを閉じます。
- Eclipseを終了します。
rm -rf org.Eclipse.core.resources
(新しく作成したディレクトリを削除します。)mv org.Eclipse.core.resources.bak/ org.Eclipse.core.resources
(元のディレクトリを復元します。)- Eclipseを起動して、作業を開始します。 :-)
私も同様の問題を抱えていました。 Eclipse(Luna)は通常スプラッシュ画面で起動し、メインウィンドウを開いてすぐにフリーズしました。 Eclipseを実行している私にとって
Eclipse.exe -clean -refresh
問題を修正しました。
-consoleおよび-consoleLogフラグを使用してEclipseを再起動してください。これにより、OSGiを操作してプラットフォームの出力を確認できるときにコンソールウィンドウが開きます。 Eclipseフォルダー(Eclipse.exeがある場所)のEclipse.iniにこれらのフラグを配置できます。コンソールウィンドウで、「ss」と入力し、どのプラグインがロードおよび起動されるかを表示します。それはあなたに遅さの理由を指摘するかもしれません。 OSGiバンドルを開始および停止するには、startおよびstopと入力します。また、Eclipse.iniに「-clean」がないことを確認してください。すべてのプラグインがリロードされ、速度が低下する可能性があります。
ソフトウェアセンターと同様に直接ダウンロードでEclipseをインストールしましたが、ubuntu 12.04 LTSでは、〜/ workspaceディレクトリが削除されない限り、両方ともスプラッシュ画面でハングするようです。
スプラッシュ画面をクリックしてEnterキーを押すと、〜/ workspaceディレクトリを削除しなくても、問題なく起動することがわかりました!!
@CharlesBはおそらく私にとってほとんどの人にとってうまくいくでしょうが、Eclipseは一般に個々のプロジェクト(通常は最後のプロジェクト)を破壊するため、うまくいきません。したがって、リンクされたプロジェクトでは、.snap
および.history
を削除すると、最後のプロジェクトまたはフォルダ全体がよりよく機能すると思います:
WORKSPACE/.metadata/.plugins/org.Eclipse.core.resources/.projects/LAST_PROJ_BEFORE Eclipse_CRASHED
その後、Eclipseを再起動すると、LAST_PROJ_BEFORE_Eclipse_CRASHED
が閉じた状態で表示されます。既存のプロジェクトを開いてワークスペースに再インポートすることはできないため、削除してください(リンクされたプロジェクトにはまだ.project
があります)。
私にとっては以下が修正されました
Eclipse.iniで、正しいjvm.dll vmエントリを持つJava 8を指していることを確認します。
-vm
C:\Program Files\Java\jre1.8.0_131\bin\server\jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.8
-XX:+UseG1GC
-XX:+UseStringDeduplication
-Dosgi.requiredJavaVersion=1.8
ローカルワークスペースの.metadataフォルダーを削除します(これが私にとってうまくいったことです)。正しく閉じられていないと、Eclipseが正常に起動できなくなる.LOCKファイルが含まれているようです。
これは完璧に機能しています。
私にとって.snapファイルの削除とorg.Eclipse.core.resourcesの名前の変更と復元は役に立たなかった。 org.Eclipse.core.resourcesフォルダー内の.historyディレクトリーを削除する必要がありました。この後、Eclipseを起動できました。
Luna4.4.2でも同様の問題がありました。しかし、このEclipseバージョンを開くのは初めてだったので、以前に使用されたプロジェクトはなかったため、上記のいずれも私にとって解決策ではありませんでした。凍結したスプラッシュ画面をクリックせずに、20分ほど待ちました。幸い、「ワークスペースの選択」画面がようやくポップアップ表示され、Eclipseが正常に動作するようになりました。
明示的なtempdir仕様でDevMode JVMを起動できます。 Antを使用してDevModeを起動し、次のJVM引数を指定しています。
Google Eclipseプラグイン経由で起動する場合も、同じ「-D」引数を使用できるはずです。
使用するtempdirはビルドプロセスの一部として定期的にクリーニングされるため、ジャンクファイルの蓄積が制御されます。
Linuxユーザーの場合。 Eclipseキャッシュのクリーンアップを行った後、スタートアップのフリーズが停止しました。 Eclipseが実行されていないときに、次のことを行いました。
その後、Eclipseの起動時間は5〜10秒に戻りました。
私の場合、ワークスペースを選択した後、「view.ui」の読み込み中にスプラッシュ画面でフリーズしていました。修正プログラムは、Eclipse -clean -clearPersistedStateで実行されていました。