@Nikita Rybakの答えには良い点がありますが、詳細が不足しています。自分自身を深く考えずに単純にアイデアを得ることができません。以下は私が考えたものであり、今では理由を完全に理解する必要があります。
4つのアクセス修飾子。第1レベルがパブリックで、第4レベルがプライベートであると想定します（このテーブルに順番に基づいています）。最初に知っておくべきことは、クラスをトップレベルでプライベートとして定義できない理由です。
したがって、「プライベートクラスfoo」（定義されたプライベートメンバー、つまりクラス自体がメンバーである）が許可する場合、外部（メンバーを含む）は何ですか？ファイルスコープ？いいえ、単一ファイル内の複数のクラスでさえ別々のクラスファイルにコンパイルされるため、ファイル外部は無意味です。つまり、アウターはパッケージです。ただし、第3レベルのデフォルトのアクセス修飾子は、すでに「package-private」を意味します。したがって、第4レベルのプライベートアクセス修飾子は使用/許可されません。
ただし、直接外部はパッケージではなくクラスであるため、ネストされたプライベートクラスは許可されます。例：
class PrivateNestedMain {
private static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
「保護されたクラスfoo」が許可した場合はどうなりますか？保護された主な特性はサブクラスであるため、outer（package）は（スコープまでですが、それでもオプションです）サブクラスのスタイル、つまりサブパッケージ、またはを提供する必要package A extends package Bがありますが、そのようなことはわかりません。したがって、protectedは、外部がパッケージである（つまり、そのようなサブパッケージのものがない）トップレベルで完全な可能性（メインスコープはサブクラス全体）を使用できませんが、protectedは、外部がクラスであるネストされたクラスで完全な可能性を使用できます（つまり、サブクラスにすることができます）：
class ProtectedNestedMain {
protected static class Inner {
public static void main(String[] args) {
System.out.println("Hello from Inner!");
}
}
}
上記の「可能性を最大限に使用することはできません」の意味は、ことは、外サブクラス、ので、それに起因するが、単にサブクラス全体に到達できないと述べたことを注意実際に保護を許すことはできない、それはパッケージの複製ジョブを避けるために、好みの問題です-外部がサブクラス化できない場合はプライベート。以下を参照してください。
私の混乱は主にhttps://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.htmlの有名なテーブルが原因です：
第1レベル（パブリック）と第3レベル（パッケージ-プライベート）が許可されている場合、いったいどのようにして第2レベル（保護）の中間が許可されないのでしょうか。
パブリックサポートサブクラスは非常に誤解を招きやすいです。この表を読む正しい方法は
アウターにサブクラス機能がある場合は、パブリックサポートサブクラス。
同じ誤解を招くような適用がpackage-privateに適用され、package-privateはサブクラス（セル内のN）をサポートしていませんが、サブクラスの概念が外部に適用されることを意味しません。
つまり、外部でサブクラス機能が使用できない場合は、サブクラス列を無視する必要があります。
これでわかるように、protectedとpackage-privateの両方が同じレベル（YYN）になり、中間レベルが許可されない理由について混乱することはなくなりました。全体として、Javaは混乱を避けるために保護されたパッケージプライベートのみを選択し（これは選択の問題ですが、保護された主な特性はサブクラスであるため、パッケージプライベートが優れています）、その結果、トップレベルで許可されるアクセス修飾子は2つだけです。
トップレベル-パブリック、またはパッケージプライベート（明示的な修飾子なし）。