なぜArrayList一般的にダブルエンドで実装されていないのですか？これは、前面と背面での高速償却挿入をサポートしますか？
前者よりも後者を使用することに不利な点はありますか？
（私はJavaについて話しているだけではありません。他の言語のデフォルトである両端配列リストを見たことがありませんが、Javaはここでの良い例にすぎません。）
*編集：私はもともとそれらを「配列両端キュー」と呼んでいましたが、それは私の側の誤解でした。私はキューについて話していませんでしたが、両端の配列リストについて話していました。
ArrayListは単純です。エントリは0から始まり、最後に何かを追加できます（配列が長くなる可能性があります）が、リストのエントリ#Xは常にbacking_array[X]です。
ArrayDequeはもっと複雑になります。シーケンスの開始を追跡する必要があることに加えて（O（N）シフト/シフト解除が必要でない限り、0から開始することが保証されなくなるため）、もう一方の端が「空"。その余分な複雑さには代償が伴います。より一般的なケース（リスト）では、RTLは、dequeで必要なすべてのチェックとインデックス計算を実行する必要があり、実際の理由もなくアプリの速度が低下します。エントリ#Xはになりbacking_array[start+X]、境界チェックにも追加の計算があります。
したがって、deque機能が本当に必要でない限り、少なくとも配列をいじっているときは、リストを使用する方が簡単で効率的です。
dequeは、FIFOまたはLIFOの方法でデータにアクセスする場合にのみ使用されます。これらの共通インターフェースは、n番目の要素を取得する方法を提供しません。手動で行う必要があります。実際、JavaDequeを見るとここでは、n番目のメソッドが提供されていないことを理解しています。これは、データのグループにインデックスを付ける必要がある場合にその使用を回避するのに十分なはずです。
わかりました。通常の配列の代わりに配列両端キューとして実装できますが、これにより、デフォルトではなく、必要なときに考慮すべき機能が追加されます。それ以外の場合は、できるという理由だけで、単純な問題に対してより複雑なデータ構造を使用することを正当化できます。
私見では、最近のアレイ間の相乗効果と、マシンの近くにコードを記述したときにアレイがどのように実装/管理されたかという問題もあります。
Javaでは、ArrayDequeはListを実装していません。なぜそうならないのかわかりません。
通常のArrayList実装は、アイテムを繰り返し追加したり、アイテムを読み取ったりできるものが必要なコードの通常のgo-toコレクションタイプです。ArrayListこのタイプはそれよりもいくつかの機能を提供し、それらの一部を省略すると、主な使用例でタイプの機能が強化される可能性がありますが、操作が1％遅くなった場合に、ユニバース全体で費やす必要のある余分なCPU時間の合計は重要であること。
さらに、2つの賢明な動作モデルがあるため、両端配列リストへのインデックス付きアクセスがどのように動作するかは明確ではありません。低い番号の端からアイテムを追加または削除すると、既存のすべてのアイテムの番号が変更されるように指定できます。 、またはアイテム0の前に挿入されたアイテムのインデックスが-1になるように指定できます（既存のすべてのインデックスはそのまま残ります）。アイテム0の前に2^32を超えるアイテムを追加すると（メモリ不足を避けるためにもう一方の端から十分なアイテムを削除しながら）、アイテムMIN_INT、アイテムMAX_INT、MAX_INT-1などが追加されます。いくつかの方法がありますが、他の方法では非常に便利です（たとえば、実装により、反対側で動作するライタースレッドとリーダースレッドによる同時インデックスアクセスが可能になる場合があります。
さまざまなダブルエンドコレクションタイプの用途は確かにありますが、それは、ダブルエンド機能を追加することが一般的な使用例に何らかの価値を追加することを意味するものではありません。