Use arrays to initialize the member variables of MultilevelSplitQueue

[tangjiangling]

Previously in MultilevelSplitQueue, levelScheduledTime and
levelMinPriority were initialized using arrays, while
levelWaitingSplits and selectedLevelCounters were initialized using
List, this commit unifies the style by making all these variables
initialized using array style.

Release notes

(x) This is not user-visible and no release notes are required.

[hashhar]

@tangjiangling Can you rebase to make sure CI results are fresh and I can merge this then.

[tangjiangling]

Rebased from master.

[martint]

Unless there’s a compelling reason to use arrays (measurable performance improvements, memory, etc), we should be using lists.

[hashhar]

In this specific case there's no benefit to using lists as far as I can tell. And note that all other code there already uses arrays. I think this change brings some consistency without any additional cost.

[tangjiangling]

Agreed, we have only a small number of elements (5):

• In terms of performance or resource usage, there is little difference between using array or list.
• In terms of ease of use, we can consider using list, as it has a richer api

The main purpose of this PR is to unify the types of variables, so if I understand you correctly, you agree that I unify them into lists, right? @martint

[martint]

Unifying them makes sense (either to lists or arrays, as appropriate). I'd like to understand why they are different, though (it may require going through the history of changes)

[tangjiangling]

I'd like to understand why they are different, though (it may require going through the history of changes)

Following your suggestion, I have checked the change history:

d743fb0 introduces the following 3 variables:

• levelWaitingSplits : List
• levelMinPriority : AtomicLong[]
• selectedLevelCounters : List

c05e081 introduces the following 1 variable:

• levelScheduledTime : AtomicLong[]

From the change history, I think there is no special reason to choose list or array, maybe just the author's development style at that time

So I'll keep this PR as it is, and you can double-check to see if I'm missing something.

[hashhar]

@martint This is ok to merge, correct?

EDIT: I assume yes by your reaction to the previous comment. Merging, feel free to do a post-merge review if needed.