Java

Hoe maak je een stack universeel voor werken niet alleen met Integer, maar ook met String en aangepaste objecten?

Waar moet je rekening mee houden bij het maken van een index op een grote tabel in productie?

Schrijf je eigen klasse die een stack implementeert, met methoden push, pop en peekMax, die het maximale element in de stack in O(1) retourneert.

Waarom is SELECT FOR UPDATE nodig in plaats van synchronized? En waarom pessimistische locking in plaats van optimistische?

Waarom treedt een StackOverflowError op als er geen lokale variabelen zijn? Waarmee wordt het geheugen gevuld?

Wat te doen als processFile niet kan worden uitgevoerd na het bevestigen van de transactie?

Waarom kun je niet gewoon een variabele max gebruiken in plaats van de tweede stapel?

Er is een systeem dat gebruikers de mogelijkheid biedt om met bestanden in de browser te werken. Stapel standaard: Java, Spring, React, Postgres. Bestanden worden opgeslagen in het bestandssysteem op de backend, bestandsmetadata in de database. Het team heeft een functie geïmplementeerd: @Transactional public void process(String oldName, String newName) { Long id = exec("select id from file where name='" + oldName + "'"); // uitvoeren van een databasequery processFile(oldName, newName); // hernoemen van het bestand op de schijf exec("update file set name='" + newName + "' where id = " + id); // uitvoeren van een databasequery }

Kan de stack in geheugen worden geoptimaliseerd om geen x2 verbruik te hebben?

Welk type index gebruiken voor zoeken in het midden of aan het einde van een string (LIKE '%tekst%')?

Er is een backend, er is een gebruikersinterface. De technologische stack is standaard: Java, Spring, React, Postgres. Taak: Ontwerp een REST-endpoint dat gegevens uit 3 bronnen moet ophalen en aan de UI moet leveren, terwijl het maximale mogelijke doorvoer en minimale responstijd wordt gegarandeerd (max/mini criteria op basis van onze specifieke voorwaarden, omdat er in feite geen magische oplossing is en een compromis moet worden gevonden). Het is bekend dat de verwachte piek RPS voor deze endpoint 200 zal zijn. Bekende details over de bronnen: 1. Bron - onze database, query duurt ongeveer 15 seconden. 2. Bron - gerelateerde REST-service, degradeert tot 2 minuten bij 100 RPS, reageert in 5 seconden in normale modus. We kunnen het gedrag van deze bron niet wijzigen. 3. Bron - gerelateerde REST-service, reageert willekeurig (geen patronen vastgesteld) met 503-fouten, in normale modus reageert hij in 10 seconden. We kunnen het gedrag van deze bron niet wijzigen.

Schrijf een heel eenvoudige methode die bij uitvoering een StackOverflowError gooit.