Should I force unboxing when using an Iterator on a collection of Wrappers?

Let's go in parts.

First , the code you present does not compile . The problem is that you can't infer the data type from here:

Set<Integer> statueSet = new TreeSet<>(Arrays.asList(statues));

Actually, the inferred data type is Integernothing but int[]. It happens that the signature of the method is Arrays#asList(Object ... varargs). int[]is a class , so by having the following:

int[] statues = { 1, 2, 3 };
List<int[]> statuesList = Arrays.asList(); //compila
System.out.println(statuesList); //imprime algo como [ @ab3421 ] puesto que llama a `int[].toString()`

To make your code compile, you either change the data type of the parameter from int[]to Integer[]or change the Set<Integer>to Set<int[]>. I recommend changing the data type of the parameter Integer[].

Second , the autoboxing in your code is executed only in one part:

//aquí
for (int statue : statueSet) {

The improved for, which has been included since Java 6, is syntax sugar for the following (except for arrays of primitives):

for(Iterator<Integer> it = statueSet.iterator(); ; it.hasNext()) {
    Integer miVariable = it.next();
    //...
}

In this case, since you force the iteration to be done with a primitive, the unboxing will be done at that moment only:

for(Iterator<Integer> it = statueSet.iterator(); ; it.hasNext()) {
    Integer miVariable = it.next();
    int statue = miVariable.intValue();
    //usar la variable statue para el código dentro del for...
}

Now, what is the performance cost of boxing/unboxing?

I did some tests using Java 1.8.0_65, JMH 1.19 (because the tests using it System.nanoTime()are very innocent) on MacOS X Sierra, 2.7 GHz Intel Core i5 processor, 8 GBs of ram, 256 MBs dedicated for the JVM. These are the results:

• Loop through the elements of an array of 10 elements, without unboxing:

  0.001 ±(99.9%) 0.001 ms/op [Average]
  (min, avg, max) = (≈ 10⁻³, 0.001, 0.001), stdev = 0.001
  CI (99.9%): [0.001, 0.001] (assumes normal distribution )

• Loop through the elements of an array of 10 elements, with unboxing:

  0.001 ±(99.9%) 0.001 ms/op [Average]
  (min, avg, max) = (≈ 10⁻³, 0.001, 0.001), stdev = 0.001
  CI (99.9%): [≈ 10⁻³, 0.001] ( assumes normal distribution)

• Loop through the elements of an array of 10,000 elements, without unboxing:

  0.001 ±(99.9%) 0.001 ms/op [Average]
  (min, avg, max) = (≈ 10⁻³, 0.001, 0.001), stdev = 0.001
  CI (99.9%): [≈ 10⁻³, 0.001] ( assumes normal distribution)

• Loop through the elements of an array of 10,000 elements, with unboxing:

  0.001 ±(99.9%) 0.001 ms/op [Average]
  (min, avg, max) = (≈ 10⁻³, 0.001, 0.001), stdev = 0.001
  CI (99.9%): [≈ 10⁻³, 0.001] ( assumes normal distribution)

In short, your concern about cpu consumption and execution time of boxing and unboxing operations is irrelevant . This is probably not a bottleneck.

The benchmark code can be found here (somewhat long code).

I have done some tests with the following code for unboxing:

public class Test {
    public static void test(Set<Integer> data) {
        for (int i: data) {
            System.out.println(i);
        }   
    }
}

And when compiled it becomes:

public static void test(java.util.Set<java.lang.Integer>);
    Code:
       0: aload_0
       1: invokeinterface #2,  1            // InterfaceMethod java/util/Set.iterator:()Ljava/util/Iterator;
       6: astore_1
       7: aload_1
       8: invokeinterface #3,  1            // InterfaceMethod java/util/Iterator.hasNext:()Z
      13: ifeq          39
      16: aload_1
      17: invokeinterface #4,  1            // InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
      22: checkcast     #5                  // class java/lang/Integer
      25: invokevirtual #6                  // Method java/lang/Integer.intValue:()I
      28: istore_2
      29: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
      32: iload_2
      33: invokevirtual #8                  // Method java/io/PrintStream.println:(I)V
      36: goto          7
      39: return
}

That is, it is something similar to:

public class Test {
    public static void test(Set<Integer> data) {
        for (Integer i: data) { //Se hace un casting desde Object
            int aux=i.intValue();
            System.out.println(aux);
        }   
    }
}

Then the overhead is not very large, especially in terms of memory, since the "primitive" value is already in the wrapper.

Now the opposite case, autoboxing:

public class Test2 {
    public static void test(Set<Integer> set,int i) {
        set.add(i);
    }
}

Which becomes:

public class compilerTest.Test2 {
  public compilerTest.Test();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void test(java.util.Set<java.lang.Integer>, int);
    Code:
       0: aload_0
       1: iload_1
       2: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
       5: invokeinterface #3,  2            // InterfaceMethod java/util/Set.add:(Ljava/lang/Object;)Z
      10: pop
      11: return
}

What comes to be:

public class Test2 {
    public static void test(Set<Integer> set,int i) {
        Integer aux=Integer.valueOf(i);
        set.add(aux);
    }
}

In this case, the overhead is somewhat higher, creating a new object for each primitive value (and even this may be mitigated by the cache that wrappers usually create , in such a way that if a value already has an instance of said wrapper it is reuse ¹ ), but in most cases personally I would consider it acceptable.

In any case, doing "micro-optimizations" is something that should only be done if we are sure that this code is a performance bottleneck for our application: Will this method be called very often? When called, how long is the CPU processing it?

¹ This is what often makes the following code work, confusing Java newbies:

Integer a=5; //Autoboxing;
//Autoboxing, se detecta que ya se creó un Integer con el mismo valor y lo reúsa
Integer b=5; 

if (a==b) { ... } // Funciona aunque no se use a.equals(b)